[JDEV] Jabber documentation question; XML parsing worries; and ease of d evelopment

[Justin Kirby]

Replies in-line...

On Mon, 2002-05-20 at 11:33, Gallo, Felix S. wrote:
> 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?

state chart!! cool...would love to see one :)

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

My solution to this problem was to hack a TCP/IP input stream for the
XercesC parser. Use SAX and use the tokenized parsing functions. This
essentially offloaded all those issues into XercesC so I didnt' have to
worry about it :)



>  
> 3.  This is more a plaintive bleat than a question: why are there about ten
> different 60% complete C/C++ libraries, dammit? :)
>  

My (probably way off-base) reason why there are a bazillion C++
libraries none of which are complete:

1. completeness is relative ;)
2. one size does not fit all.

yeah, re-use is nice... but a lot of the time its a myth propagated by
academics. trade-offs are what the real issues are... and I think the
major jabber C++ libraries do a good job filling their own trade-off
niche.

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

-- 
JID: Zion at openaether.org

      ,/^^^^\,
     /       \\.
   /|
  /|  /''\___/
        /''\__/  |/
     /''\__/    |/
      \\      ./
       `\..../

http://www.openaether.org