Re: [xml] xmlParseChunk

[Brian Stafford <brian stafford office-logic com>]

Daniel Veillard wrote:
> On Wed, Sep 05, 2001 at 05:24:54PM +0100, Dan Ellis wrote:
>
> > On Tue, 4 Sep 2001, Daniel Veillard wrote:
> >
> > >  the parser will get called for at least 80 bytes of input. This
> > > will mean on each network packet (nobody's using ATM, right), it's
> > > an ad-hoc value to represent a line of input. You're the first
> > > suggesting lowering it so far.
> > The reason I ask is because it would be nice (in a situation where you
> > know there will be nothing after the closing root element) to have the
> > parsing stop in response to the end of the document. That way, when
> > sending XML-based requests over a network there'd be no need to include a
> > header just to specify the length of the document.
> >
> > Of course, if you know a better way of achieving the same end, that'd be
> > good too.
>
>   If you're stacking multiple document onto a single stream, you have
> to handle the end of the document. It's clear from the XML spec because
> you can have Misc* after the end of the root. The parser cannot make that
> decision, and whoever designed to put a succession of document on a single
> stream must have provided a way to signal the document end. If not their
> design is plain broken per the XML specification, sorry :-\
<snip/>
>   => Broken design IMHO

I agree with D.V.   I should have thought that, in general, it is difficult
for *any* parser to infer the end of data from the content of the data
stream.  Protocols must mark the end of their payload data somehow.

For plenty of examples on how to design (or how not to design) a network
protocol, I'd strongly reccommend looking over the current set of RFCs
which are freely available.  Its also worth looking over the active
working groups within the IETF (http://www.ietf.org/) or the W3C
(http://www.w3.org/), there may be someone else working on something
similar to your problem.

Also try having a look at http://www.bxxp.org/
--
Brian Stafford