Re: Incremental XML Parsing

[Ari Johnson]

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
>