Re: [xml] xml reader interface and sockets

[Daniel Veillard <veillard redhat com>]

On Fri, Jan 10, 2003 at 07:09:58PM -0500, Sean Middleditch wrote:
> On Fri, 2003-01-10 at 18:40, Daniel Veillard wrote:
> must have a weird address in there.  I'll fix it so I can send mail the
> normal fun way.  ^,^

   yup, that works, thanks !

> > > 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.  ^,^

  Well it's a balance. At the moment I reused the very simple
part which is part of the C# API, but more complex model are interesting
and should be relatively easy to implement (if not to use).

> > > 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.  ^,^

  okay, also see the existing XmlReader APIs from C# in case there
 is overlap 
   http://dotgnu.org/pnetlib-doc/System/Xml/XmlReader.html
I found also the parsed property in Microsoft DOM extensions:
   http://www.devguru.com/Technologies/xmldom/quickref/obj_node.html
as being relevant.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/