bug comments 605, 606, 627
bryan at bcpub.com
Thu Sep 18 07:37:35 PDT 2003
This is a combination email of several bug reports.
[Bug 605] Conditional execution
I don't enjoy supporting this type of operation. Even
if it is possible. The more I work with this type of XML,
the less I like <cond>. XML is not a programming
language. Although some folks pretend it is... :)
imho the whole idea of ALFS <cond> anything
needs to be rethought. From the conference call, everyone
seemed to support this rethinking, maybe even dumping
<cond> processing in the backend. Or at least making good
rules about how it will be done and what are the limits.
[Bug 606] New: Continue executing, when some element fails
>Support for <options>ignore_error</options> or some common attribute could be
>added to most elements, to force execution when we know it will fail. Useful
>for some "make check"s, for example.
After discussing this with Gerard, I think this option of how to
bypass the checks is a fall back option. The correct option seems
to be deal with it in the package's patch files, not in the automation
[Bug 627] New: Use libxml2's SAX for parsing profiles
>Use SAX instead of current way of parsing profiles. This will probably end
>up as WONTFIX, remembering some previous discussions.
SAX is great. I fully recommend trying out SAX. Amin uses SAX as the
primary processor for about everything. The only other XML processing
that Amin uses is a Twigish DOM like processor called MiniDoc. The only
thing that SAX is not good for is in memory document changing. It can be
done, but the more complex the process, the harder it is with SAX. We only
use MiniDoc for creating the "restart" profile in the frontend.
In terms of what ALFS is trying to do, SAX is the best XML processor choice.
When you think of this whole backend process in terms of SAX events,
If this is going to remain a WONTFIX in nALFS, I'll be happy to show anyone
how SAX can work with ALFS.
More information about the alfs-discuss