Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] reading an xml from a socket

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Steve Loughran" <steve.loughran AT gmail.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] reading an xml from a socket
  • Date: Mon, 23 Oct 2006 10:41:56 +0100

On 23/10/06, Wolfgang Hoschek <wolfgang.hoschek AT mac.com> wrote:
On Oct 22, 2006, at 3:50 PM, lneves wrote:

> Wolfgang Hoschek wrote:
>
>> But to put the discussion into perspective: Any reasonable higher
>> level protocol defines a generic framing mechanism, thereby omitting
>> the need to think about XML specific framing anyway.
>
> Unfortunately there are some protocols that are not reasonable. XMPP
> [1] is one them.
> It's basically a stream of XML fragments dumped into a socket and
> it's up to the
> angle brackets to do the framing. What is your suggestion to deal
> with something like
> XMPP?


XMPP basically says a (TCP) connection is used to transport a single
XMPP stream, which is an open-ended XML document: the document has a
root element that can have arbitrarily many child elements. During
the life of the stream, the entity that initiated it can send an
unbounded number of XML elements over the stream. Errors (e.g. not
wellformed XML) are unrecoverable, implying closing the connection.
Presumably errors are unrecoverable because XMPP is lacking a
sensible framing mechanism, as you point out.

Well, TCP isnt meant to have transient outages, is it. Its the
illusion of a stream over packets after all.

Having been doing some XMPP stuff (much more preferable than
imlpementing WS-notification, I can assure people), you get some
interesting failures which are actually recoverable from by trying to
reconnect, ideally with backoff with extending delay including a bit
of jitter that is not entirely clock based (*)

xmpp endpoints can roam, their proxy settings can change, laptops can
enter/exit hotspots. A good xmpp app recovers from this in the
background. Ones that pop up dialogs or dont reconnect, dont lead to
very good user experiences.


If the question is how to read and write an XMPP stream with XOM:

- for writing: use a StreamingSerializer [1].
- for reading: use the XOM NodeFactory of a StreamingPathFilter [2]
with a "/*/*" path and any XOM Builder. A user defined handler will
be called for each XMPP stanza and given the corresponding XOM fragment.

[1] http://dsd.lbl.gov/nux/api/nux/xom/io/StreamingSerializer.html
[2] http://dsd.lbl.gov/nux/api/nux/xom/xquery/StreamingPathFilter.html


I've been doing some work with Xmpp via the Smack Library, but not
(yet) done the bridging to Xom documents. For that I'd need to
subclass the Smack packets and their toXml() method, delegating that
to the xom graph that the packet had underneath, and doing something
similar underneath.

steve

(*) because you have some interesting failures with 500 machines all
on the same clock, all booting up and trying to connect at the same
time.
-




Archive powered by MHonArc 2.6.24.

Top of Page