[jdev] Re: Re: Re: Parsing XMPP/Jabber protocol

[Bill de hÓra]

Heiner Wolf wrote:

> While implementing a Jabber client, endDocument() is just not relevant.

I think the problem here could be resource management on servers not 
clients waiting for the next few bytes. I say could be because I have no 
data and it might be a non-problem, but instinctively the ideal of 
holding XML parse streams open like this has my back up - framed octet 
streams, sure; XML events, hmm.


> What worries me much more is that all developers use SAX parsers and
> anyone has to re-create the XML structure from those
> startElement/stopElement sequences. I wonder why there is no better API
> than the Simple API for XML. I guess everyone who implemented the
> protocol, had to re-create the XML fragments from
> startElement/stopElement sequences. For streaming XML SAX is not enough.
> Developers would need a bit more, a mixture of DOM and SAX. A kind of
> "Fragment API for XML" that stream-parses XML like SAX, but returns
> fragments as DOM like data structures.

You still have to manage the buffer/frame coming off the socket while 
building the DOM tree. The natural solutions seems to be to layer a 
framing mechanism on top of SAX to manage the network i/o possibly 
exposing a pull style API. SAX may look like a streaming API but it is 
really designed for conserving memory footprint while crunching through 
documents that are "to hand" locally. It's not designed for network data 
streams. I imagine life would be simpler for your fragment approach if 
you were not modeling the entire message stream as a single XML document 
and were working with discrete XML documents instead of child nodes. I 
definitely would not want to be holding onto full DOM trees or some such 
while managing thousands of IM conversations.

cheers
Bill