Re: Incremental XML Parsing

[David Sugar]

This also has some use in Bayonne's XML parser, since Bayonne can make a
web query to parse and XML script document.  Usually it had to also wait
until the entire fetch was completed which also is an indeterminate size
document, typically from a web site.  Maybe I can now do something a bit
more interactive...

On Wed, 9 Oct 2002, Ari Johnson wrote:

> 
> I wouldn't recommend taking out the read or close virtuals at all.  Keep
> everything as it is, but with the change that I made in my patch.  My
> patch basically emulates a pull parser by using libxml2's push interface,
> which is advantageous because it means that when the read virtual returns
> a given number of bytes that contain so many complete xml elements, those
> elements get parsed right away, rather than waiting for the whole file to
> be read (or at least a full buffer of unknown size to be filled) before
> libxml2 actually parses anything.  This means that people can call it
> exactly as they always have, but that it simply adds the feature that I
> needed.
> 
> If you wanted to add a push interface, I would recommend superclassing
> XMLStream and doing the following in the superclass:
>  - no the open/read/close virtuals
>  - parse(const char * buffer, int len) sends the given buffer off to
>    libxml2 (as per in the while loop in my patch; I'd recommend using
>    a different name than parse() though, to avoid confusion)
>  - end() or complete() or done() or youNameIt() tells libxml2 that the
>    end of input has been reached; this will be called by the user, as
>    per the end of my patch's while() loop
> 
> Then, XMLStream will be a subclass of the new class, and it will simply
> implement its various virtuals, and parse() will now pass what it read()s
> down to the parent class's parseWhatever(), and call end() at the end of
> input.
>  -- Ari Johnson
> 
> On Wed, 9 Oct 2002, David Sugar wrote:
> 
> >
> > The read and close virtuals ultimately have to be called, because those
> > can be overriden and bind xml to streams or to other things such as
> > passed xml memory buffers.  I think having a seperate parsePartial may
> > also be useful, and we should pass the length of the buffer to request for
> > that.  What if we broadcast XML content over multiple UDP
> > packets, for example.
> >
> > On Wed, 9 Oct 2002, Federico Montesino Pouzols wrote:
> >
> > >
> > >   Yes, I think this patch should go on both the stable and
> > > unstable branches. It adds a very interesting capability and should
> > > not harm applications that do not need partial parsing.
> > >
> > >   It is also interesting to discuss the following two points:
> > >
> > >   * The patch from Ari implements the "Method 1" he described in
> > > his first mail. Should we also add a special parse() -say
> > > partialParse()- method that implements the "Method 2"? I suppose this
> > > method would be almost equal to the normal parse(), except that it
> > > would run just one iteration of the loop.
> > >
> > >   * What do we do with the read() and close() virtual methods
> > > now?  Should we remove them, or would it be valid to call read()
> > > inside the loop and close() after the loop? I think this last option
> > > makes sense but I am not too certain.
> > >
> > > On Wed, Oct 09, 2002 at 01:39:14PM -0400, David Sugar wrote:
> > > > We may want to have this in the RELEASE1 tree as well...?  It seems 
> > > > harmless
> > > > enough for existing code.
> > > >
> > > > On Wednesday 09 October 2002 13:04, Ari Johnson wrote:
> > > > > I did go ahead and implement this; took about 3 minutes total.  My 
> > > > > patch
> > > > > to xml.cpp is attached to this message.
> > > > >  -- Ari Johnson
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Bug-commoncpp mailing list
> > > > address@hidden
> > > > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> > >
> >
> >
> >
> > _______________________________________________
> > Bug-commoncpp mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/bug-commoncpp
> >
> 
>