Patch for nALFS
mark.uzumati at virgin.net
Wed Dec 19 11:38:55 PST 2001
On 2001.12.18 17:42 Paul Campbell wrote:
> Yes. Hmmmm! mmm? Could we not begin to think in a more eXtensible way?
> can't speak from a C programmers perspective, nor any other much language
> much experience, but what about plugin handlers? Do nALFS and ALFS fall
> when they do not recognise an element? Should / could they not just
> display it
> as --> [Unknown element] <meta>. I suppose this would lead to a minor
> mod at
> least, in that the parser would need to search the package element to
> find the
> <name> and <version> elements, as it could be contained in a <meta> or
> element? aka package/descendant::name (Xpath) *I* think in my limited
> knowledge of XML, that this kind of element selection is for the better
> as it is flexible.
> So I think that a version 3 syntax, might by likely, but, can we pause,
> consider 4, 5, 6, 7 ...... Making them simple extension rather than
Actually the structure of both perl ALFS and nALFS make dropping in new
handlers a piece of cake, so long as they don't do anything _too_
fundamental to operation. I just ignore unrecognised elements, and from
what i've looked at in Neven's code i think he does a simple validity
check, not sure exactly but giving an "unrecognised" or "unsupported"
message probably wouldn't be hard. I should put in a check, just haven't
decided how to do it yet :) While we're on the subject Neven, love the way
you use that HANDLER macro in elements.h, inspired coding !
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message
More information about the alfs-discuss