[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [xml] xml reader interface and sockets



On Fri, 2003-01-10 at 18:40, Daniel Veillard wrote:
> On Fri, Jan 10, 2003 at 06:04:26PM -0500, Sean Middleditch wrote:
> > Hi,
> 
>   Hi,
> 
> first I suggest you join the list, what you're asking raise discussion
> and I don't want to have to amnually approve your posts to be able to
> discuss.

Hmm, thought I was subscribed, seeing as ho I receive mail from list -
must have a weird address in there.  I'll fix it so I can send mail the
normal fun way.  ^,^

> 
> >  From what I've read of the new xml reader interface, it's only lets you
> > pull in the parsed data.  It doesn't let you push in the raw xml.  I'm

<snip/>

> > I'm current using Expat and it's sax-ish interface; however, that's
> > turning out to be complete hell (since I need to parse the data into a
> > tree form, but one that doesn't mirror the XML format, so I have tons
> > and tons of state to track and such; doesn't help that Expat doesn't
> > validate or allow error codes in the callbacks...)
> 
>   SAX has advantages, but in general it's too complex.

Way too complex... ;-)

> 
> > Anyways, the point of this babbling, will it be possible to feed chunks
> > to the XML Reader interface?
> 
>   That could relatively easilly be extended. BUT (of course there is a 
> negative side) it makes the interface harder. The current interface is simple
> because it's a completely consumer controlled processing model. The SAX
> model is completely producer controlled. The existing interface is doing
> a full conversion of control from the producer to the consumer, but will
> block on I/O input. One of the key point of the current interface is that
> it should not use too much data locally, if processing is too slow and fed
> from a socket, the transfer rate will get lower but the processing point
> won't buffer data.

Right.  There could be a few tricks to simplify the interface, I would
think.  Enough of the core should be the same to provide a few small
wrapper interfaces depending on your needs - dead simple or slightly
complex.  ^,^

> 
> > If not, does libxml2 offer another
> > interface besides SAX that might fit?
> 
>   Basically there is already a progressive I/O interface:
>      int
>      xmlParseChunk(xmlParserCtxtPtr ctxt, const char *chunk, int size,
>                    int terminate);
> which is the core of the XmlTextReader process. I suggest you look at
> xmlTextReaderPushData() and xmlTextReaderRead() in xmlreader.c which
> are the core routine controlling the XmlTextReader. Based on this
> you may be able to suggest extension to the existing interface:
>     - is there nodes/input data to process ?
>     - push more available data
>     - complete the parsing of a given subtree
> 
> As I said the current interface should allows really interesting extensions
> to the processing model. Mixing Push and Pull, data controlled but tree
> based APIs should be doable too.

Righty, OK.  I'll have to dig around a bit and see what I can
accomplish.  Thank you very much.  ^,^

> 
> Daniel
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]