perl status update

Mark Ellis mark.uzumati at virgin.net
Sun Dec 23 04:37:30 PST 2001


On 2001.12.21 05:53 Jesse Tie-Ten-Quee wrote:
> Yo,
> 
> [NOTE: Please check out the reference URL's i have at the bottom]
> 
> It's great to see so many ppl are still interested in ALFS; I've been
> spying on you guys every chance i could get, some things that have been
> done are awesome. (*patpats Neven* great work!)
> 
> Allthough i've noticed a number of technical problems with some of the
> choices that have been made, you guys are doing a good job either way
> and working on fixing some of those issues.. i'll not get into that thou
> tonight, i don't have the time to explain everything i mean by that... i
> wish i did, but nothing i can really do untill January comes around =/)
> 
> I've just written this down fairly quickly, it's a bunch of cut and
> pasting from my head, so if anything doesn't make sense or is incorrect
> please point it out.  I figured i should post this thou, considering
> some of the things i've been hearing on IRC and reading on this list,
> either way.. enjoy =)
> 
> Anyways...
> 
> On Wed, Dec 19, 2001 at 11:48:50PM +0000, Mark Ellis wrote:
> > I've glanced at SAX, got intrigued, decided i didn't have time to learn
> 
> > it. Might be worth another look later on though.
> 
> In all general terms, SAX is the best solution for writting ALFS
> implementations.  There are basiclly two ways to parse a file under
> XML: Events and Trees.
> 
> [stolen from="http://www.saxproject.org/?selected=event"]
> 

<snip> explanation

> 
> DOM, which is the official W3C recommendation is the easist for
> interacting with your document. (interaction as-in, changing and
> editting it, being able to navigate the tree multiple times, etc)
> 
> SAX, which was developed around the xml-dev mailing list by the
> community to create a 'simpler' approach to parsing a document.  If all
> you want todo is responds to what your document contains, such as
> we have been doing with ALFS then SAX is perfect.
> 
> Don't discredit either API, both are used and needed for different
> things.  SAX being the simplest way to write a parser is the most
> efficient and fastest, allthough the down side to this is that it
> generally requires more work to implement for the application developer.
> DOM on the other hand, is slow and a memory hog, but in certain cases
> far easier to implement in an application.
> 
> "From a certain point if view", anyways =)
> 
> -

I'll just clarify my reply before, because this is quite an interesting 
subject that has got me derailed from what i have been working on a few 
times in the past. I had actually looked at SAX enough to figure out how 
things were done, not just how to implement them, and i agree that is a 
better way to implement ALFS, the tree of elements next to a tree of 
handlers is a bit odd. I stopped investigating this properly however when 
we started work on the include tag.

Whereas before this the frontend used XML::Twig directly rather than 
ALFS::Profile for its XML requirements, it seemed inappropriate to handle 
includes outside of the ALFS modules, so i used Profile in the frontend 
and built the include handler in to that. At this point Profile needs to 
be able to regenerate an XML document to send to the backend, so the 
benefits of DOM over SAX become apparent. I actually don't think that 
<include> is going to last the course, it was always a stopgap because we 
couldn't use XInclude, and external entities seem to do the job just as 
well, if a bit less legibly. However, i think using Profile in the 
frontend is still a good thing because it can deal with setting up flags 
for communication such as 'eltid' and a few other things i have in mind. 
It may be possible to split the parsing API using the ALFS Namespace 
route, with DOM parsing in the frontend and SAX in the backend.

<snip> some parser stuff

> 
> Out of these three, i much prefer libxml2 under C.  I've used it before
> and really like how it supports alot of the XML extensions. (XInclude
> and XSLT are two extensions we could end up using alot off in the
> future)
> 
> This is what my research and experience is telling me, at least when it
> comes to the C language.
> 
> -
> 
> Here's some extra timbits...
> 
> Jason, may i make a suggestion? You keep mention IBM's XML4C, ditch it
> and switch to it's successor, The Apache XML Project.  They took the old
> code and turned it into a beauty with Xerces (XML) and Xalan (XSLT) for
> C++ and Java.
> 
> For those hacking under Perl.. I would seriously suggest you ditch
> XML::Twig and find a much nicer option.  At the time we used it, it was
> the best we could find, but it's been a long time since then, and there
> are much nicer options (or so my perl buddies tell me :) under Perl.
> 
> Not to mention the fact that all the Perl implementations were done more
> as an experiment then as something to be used under a production
> environment. (allthough that hasn't stopped most of us!)
> 

Yep I'm definitely with this now, next year i'll do the libxml2 thang :)

Good to see you're still around Jesse.

Mark
-- 
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 mailing list