[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] xml reader interface and sockets
- From: Sean Middleditch <elanthis awesomeplay com>
- To: xml gnome org
- Subject: Re: [xml] xml reader interface and sockets
- Date: 10 Jan 2003 19:09:58 -0500
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]