Re: [xml] xmlParseChunk

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 :-\
  => 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 ( or the W3C
(, there may be someone else working on something
similar to your problem.

Also try having a look at
Brian Stafford

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]