[jdev] JSR 187 JAIN Instant Messaging 1.0 Public Review Draft

[Mikhail Zabaluev]

В Втр, 01/02/2005 в 17:54 -0600, Matt Tucker пишет:
> > - Clean separation between the core XMPP protocol and 
> > extensions (including IM). A client might be uninterested in 
> > the chat extension details, so full handling of those should 
> > be optional.
> 
> We already do this in Smack. There's a smack.jar which is core XMPP and
> smackx.jar which is extensions. There's a full provider framework so
> that people can create their own extensions as well.

>From what I've glimpsed in the Smack 1.4 documentation, there are
subclasses of IQ that actually represent stanzas with certain IM
extensions. Parsing extensions to determine that convenience subtype can
be costly for the applications that aren't interested. Also, stanzas
containing multiple extensions end up classified on the basis of some
perceived "main" extension, which is not guaranteed to be the first in
order, so the logic becomes rather hairy. Oh well, I'm nitpicking, this
is an IM library after all.

> > - Three forms of representation: stanza/extension objects - 
> > DOM-like trees - raw character strings.
> 
> Smack provides objects and raw strings at the moment but not a full DOM
> model. We've actually been working on that last part in our Whack
> library (upcoming library targeted at components). It's a packet API
> that wraps DOM4J Element objects.

OK, but does it mean that JAXP DOM is in disgrace?
Take a look at the JSO library; they use a simplified model (indeed,
XMPP doesn't need many things that DOM provides) that permits JAXP,
DOM4J, and more slender "micro" implementations.