В Втр, 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. _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
