[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] Per parser xmlGcMemSetup
- From: Daniel Veillard <veillard redhat com>
- To: Joachim Zobel <jz-2006 heute-morgen de>
- Cc: xml gnome org
- Subject: Re: [xml] Per parser xmlGcMemSetup
- Date: Sun, 6 May 2007 03:34:42 -0400
On Sat, May 05, 2007 at 10:40:22PM +0200, Joachim Zobel wrote:
> Am Samstag, den 05.05.2007, 15:28 -0400 schrieb Daniel Veillard:
>
> > if you're calling the callbacks from libxml2 just to build a tree it's
> > bad, either use one of the parsers or build the tree with the tree API.
> > Other uses are not suported, in the sense that I may break randomly
> > how the callback works.
>
> > I don't know why you are doing this but this sounds extremely fishy,
> > would you care to explain, because I'm trying to guess and mostly I see
> > only bad reasons.
>
> THis is IMHO necessarily so. Apache has so called filters that can
> modify the outgoing contents. mod_xml2 is such a filter. It runs the
> libxml2 parser to turn a stream of text buffers (called buckets by
> apache) into a stream of sax events (called sax buckets by me). Other
> filters can then modify these sax events. The sax buckets automatically
> turn back into text when they are treated as such, so no filter is
> necessary on the network end.
>
> One of such filter is mod_i18n. It checks the stream of sax events it
> passes until it detects a certain attribute and then starts building a
> small partial tree, which is modified and then turned back into sax
> events.
But mod_i18n should know it is operating on top of libxml2 parser,
so why doesn't it use the libxml2 allocation routines ? The SAX interfaces
at the C level are really parser specific, and libxml2 SAX2 have been heavilly
modified to improve performances, so I don't see why it would use a different
allocator then.
> The point with this is that it stays streaming as much as possible and
> it is also possible to do tree manipulation. It is in many cases a
> usable workaround for the sax/dom dilemma and I am already thinking
> about using the same trick for another module.
>
> It does however require to call the SAX2 callbacks.
That sounds quite complex, though there is certainly good reasons for this :-)
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]