Re: [JDEV] Some jibberish...er...jabberish philosophy.. :)

[mnygard@mmm.com]

On 2 May, dsmit@ai.uwf.edu said:

> On  2 May, Jeremie wrote:
>
> > I was going to do that(merge CDATA together during parsing)...
actually,
I
> > don't know why I didn't, lazy I guess :)
>
> You lazy bum. It's not like you *ever* put any time into coding...:)

Yeah, what's with all these classes, anyway? <grin>

> > That should be easy stuff... take a look at the xpt Expat handlers,
yours
> > will be almost identical.  The only funky thing I'm doing is the
two-teir
> > parsing via xptpool, where you are "packetizing" the branch of tags
under
> > the root tag.  Let me know if you have any ?s, I'll be busy on other
> > things for a while yet, but will be happy to help after 0.6...
>
> Hmm...I've been thinking about this. I think I'm going to take a little
> different approach (at least, based on my limited understanding of
> xpt_pool). I'm going to try and use a stack to keep track of new tags
> and data. Lemme toss this out on the table for consideration...
>
> XMLstream(s)...
>
> If you consider the nature of Jabber, it can really be summed up as the
> exchange and translation of XML streams between mediums (and, of course,
> *as* a medium). It doesn't really matter if it originates from disk I/O,
> network I/O, database...you get the picture. It can all be summarized as
> a stream of XML data. So then, a XMLstream would be a data structure
> that contains all the methods necessary for taking a stream of XML data
> and reconsituting into a data structure, and then if necessary, back to
> a XML stream. It would contain the expat parser, a packet stack for
> keeping track of packet's being assembled, and a packet queue for
> keeping complete packets in. Additionally, it could maintain a series of
> function pointers to callback functions so that when packets are ready,
> the user/lib is notified and can proceed accordingly. Overall, the
> XMLstream would be independent of where the data is coming from, it
> would only be interested in getting the data.

This is pretty similar to the approach I've taken with the Java client.  I
have a notion of a "Pipeline".  You put Jabber packets into the head of the
pipeline, and XML comes out of the other end.  By hooking up segments of
pipe, each with their own responsibility, I get very simple and flexible
handling.

A couple of examples will illustrate.  I'll show the stage name, the
downstream responsibilities and the upstream responsibilities.  The typical
pipeline for talking sockets gets constructed like this (fair warning, I
don't have the code in front of me, so I might forget a stage).
* PacketPreparer (calls "willSend" on packet | calls "didReceive" on
packet)
* PacketParser (converts packet object into mini-DOM | converts mini-DOM
into packet) [1]
* DomHandler (converts mini-DOM into byte-stream | converts byte-stream
into
mini-DOM) [2]
* SocketSender (send byte-stream | receives byte-stream)

If I want to test the input/output stages, I can replace the SocketSender
with this structure:
* PipeSplitter (sends to the "output" pipe | receives from the "input"
pipe)
[3]
* output: OutputStreamSender (sends byte-stream to an OutputStream (like
System.out) | exception!)
* input: InputStreamReceiver (exception! | receives byte-stream from an
InputStream (like System.in))

[1] The mini-DOM is a simple implementation of the Element and Attribute
objects from the W3C's DOM.  As was recently noted in this list, the whole
thing is way overkill.
[2] This is where the XML parser comes into play.  You can see how easy it
would be to support other protocols.
[3] The "output" and "input" stages are both connected to the PipeSplitter.
Imagine a Y connection in a pipeline.)

Within the client itself, there is no awareness of XML.  It just uses
"Packet" objects that represent the possible communications.  I've taken
pains to make most of this framework generic.  Supporting other streaming,
packetized protocols should be relatively simple, just a matter of
providing
different packet classes and pipeline stages.

Cheers,
-Mike