Re: xmls 0.2 released

On Thu, 2003-06-12 at 13:59, Sven Van Caekenberghe wrote:
> On Thursday, June 12, 2003, at 10:34 PM, Miles Egan wrote:
> 
> > I wonder if we could somehow pool our efforts?  The free lisp world
> > probably doesn't need two lightweight xml parsers.  I like your
> > event/dom api better than my everything-in-ram approach.  I do need
> > namespace and cdata support to do soap or beep, though.
> 
> Although I certainly don't want competing implementations, I don't see 
> why there couldn't be multiple open source CL XML parsers - the more 
> the better (how many C or Java XML parsers would there be ? - and Lisp 
> is that much more easier and fun to write a parser in - in fact every 
> programmer should try it ;-).

Fair enough. :)

> No seriously, I think that my implementation is too different from 
> yours to really merge them. My hard coded parser is uglier than your 
> approach. Mine is missing namespaces and cdata. Since we're both Open 
> Source, there can be cross-fertilization. These discussions and 
> comparisons are already just that.

Definitely.  You and James have already been a valuable source of ideas.

> BTW, I believe Franz's parser is Open Source, there is CL-XML I 
> believe, and SSAX (written in Scheme) seems very complete as well 
> (including validation) - a port of SSAX to CL could be the 'complete' 
> solution. Another problem with a pro XML parser is the need for Unicode 
> support, no ?

I started out trying to get Franz' parser working with sbcl but there
were enough Allegro-isms in there that I finally gave up.  I'd rather
not base all the stuff I plan to write on Allegro shims.  CL-XML seems
very complete and full-featured, but pretty dependent on details of CLOS
that make also make it hard to run in SBCL.  I'll take a look at SSAX. 
Thanks for the tip.

> > I've noticed you're using the same xml tag as keyword approach that
> > Franz' parser uses.  I like this approach overall.  Does it create any
> > gc issues?  If a long-running parser parses a wide variety of documents
> > with different tags will it eventually exhaust memory with all the new
> > keyword symbols?
> 
> The ultimate solution would be to make this a selectable option ;-)
> Symbols are faster and more efficient all the way. And doesn't an 
> unbound, unused symbol get GC-ed ?
> I think the symbol table implementation should use weak references.

I'm not sure.  I suppose it's probably implementation dependent.  If the
runtime does clean up the symbols then keywords do seem like a win all
around.

-- 
Miles Egan <[email protected]>

_______________________________________________
Clump mailing list
[email protected]
http://manly.caddr.com/mailman/listinfo/clump

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA+6OsdU4Jq/wH1PVERAp0mAJ9daYfC2GlJKOFGPL113T1fBdNcUgCfYy2l
BhMEHUMjDfc8TVdJIeZdEbA=
=rygz
-----END PGP SIGNATURE-----