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

[dsmith@ai.uwf.edu]

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...:)

> 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.

Okay..brain is dead. More later. I gotta get up at 06.00 tommorow.
blech. 

D.