[JDEV] Jabber documentation question; XML parsing worries; and ease of d evelopment
Gallo, Felix S.
FGallo at westernasset.com
Mon May 20 10:33:01 CDT 2002
Every so often, I buy an O'Reilly book on a lark, just to see if
the subject matter is interesting/is going to win/is fun to use/is
learnable in finite time. This year's book has been the Jabber
book. I've read it cover to cover, and needless to say, I've been
converted in a big way, and am now hacking together all manner
of crazy jabberware (those of you who know me from p5p or
from the Penguin module are now cowering in terror). However,
some issues:
1. There are a large number of states in the Jabber protocol --
messages can arrive asynchronously etc etc, but against production
jabber servers I can only find one moderately tortuous pathway to
getting logged in. Is there a master state chart which is the canonical
gospel for how Jabber works, or should I try to reverse engineer it from
jabberd, or is jabberd possibly out of compliance, or?
2. Having hacked at the high levels for a bit with the fine Perl modules,
I'm now looking into hacking at the socket-and-bits level. However, I'm
encountering two problems with all the SAX, SAX2 or SAX-like parsers I
can find: first, because a packet that looks like
PACKET: <this is="a" tag="hello world">packet</this>
could be broken up in its travels across the net into
PACKET 1:<thi
PACKET 2:s is "a" tag="hello world">pa
PACKET 3:cket
PACKET 4:</this>
...it's not at all clear when a good time to call parse() is. It looks like
in order
to deal with XML streams, one would essentially have to pre-parse the XML
stream to find the closing tag's last character, bundle that up into a
buffer and
parse that, and then start some more. Is that accurate? If not, where am I
being
dumb? If so, isn't that annoyingly painful?
3. This is more a plaintive bleat than a question: why are there about ten
different 60% complete C/C++ libraries, dammit? :)
F.
**********************************************************************
E-mail sent through the Internet is not secure. Western Asset therefore
recommends that you do not send any confidential or sensitive information to
us via electronic mail, including social security numbers, account numbers,
or personal identification numbers. Delivery, and or timely delivery of
Internet mail is not guaranteed. Western Asset therefore recommends that
you do not send time sensitive or action-oriented messages to us via
electronic mail.
**********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.jabber.org/jdev/attachments/20020520/77c19a9b/attachment-0002.htm>
More information about the JDev
mailing list