[JDEV] Jabber as COM/DCOM replacement for linux.

[Eric Andreychek]

> Let's evolve jabber, not split it up......

Well, what we're referring to isn't actually splitting Jabber up.  It's
creating two different methods of using Jabber.  One for people chatting,
another for middleware applications that need a robust interface.

> I'm sure you are right but i'd like to hear the arguement anyhow.

Well, I'm going to let Dizzy handle this one.  As he mentioned earlier
today, this is part of his argument for creating the additional
jabber:middleware protocol:

"jabber:client is a namespace geared explicility for IM.  It is
sufficiently extensible so as to allow applications to reuse it... The
problem comes in the semantics and implementation of the JSM (which
provides/implements the jabber:client namespace)."

"First off, JSM has no way (and would be difficult to modify) to support
guaranteed delivery. Secondly, it enforces certain semantics on presence
that would restrict our implemenation.  Of note, I know of two distinct
types of "presence" which JAM will need to support - point-to-point and
publish-subscribe"."
...
"This _is_ a fundamental shift in the use of Jabber."

There are more points that can be made, but thats where the two of us
left off.  His overall point though is that currently, Jabber is using
the jabber:client protocol.  It was well designed, and is doing quite
well.. but wasn't made for the type of thing middleware clients require.
So let's create an additional protocol that can handle the requirements
of middleware apps, and do a darn fine job of it.. not just hack together
something that "works" only because it's what we have now.  The current
IM system wasn't designed for the middleware/DCOM sort of thing.. so lets
admit that up front and build a protocol that _will_ handle this!

> I'd like to see this as an evolution of jabber actually.  Transports
> are distributed objects and should be accessed as such, clients should
> interface these transports by methods.  the current use of iq/set
> namespaces seems silly when compared to using an XMLRPC type approach.

Hmm.. I'll let one of the developers comment on that :-)
  -Eric



-- 
 Eric Andreychek              | Lucy: "What happens if you practice the
 Eric Conspiracy Secret Labs  |  piano for 20 years and then end up not
 eric at openthought.net         |  being rich and famous?"
 http://openthought.net       | Schroeder: "The joy is in the playing."