[JDEV] Jabber Transports - New Architecture

[Justin]

Hello,

I hate to just shoot down your idea, but here goes.

> One of the cool Jabber ideas from Day One was the idea of using Jabber to
> connect to all the different IM systems.  This never really worked out -
> the remote IM transports are constantly up & down, or completely
> disconnected. It seems Jabber has been getting away from this concept of IM
> interoperability because it has other great things to offer.

The Jabber protocol maintains interoperability between different Jabber hosts 
and clients, which is something that none of the other proprietary services 
can claim.  This is what is meant when we say Jabber is "open and 
interoperable".  Interoperability with proprietary services has always been 
an extra, as well as a temporary solution.

> First off, a central server will never work since AOL and others can shut
> off the IP.  So it's up to the client to make the connections.  The problem
> is that protocols are always changing, or being slightly modified to shut
> down "unauthorized" users.

If the big boys don't want to play, then I say we shouldn't play.  
Circumventing proprietary systems is both technically and legally annoying.  
Cat-and-mouse games are no fun.  Frankly, I wish AOL would come up with a new 
protocol that is encrypted, so that they can bring out the DMCA on unofficial 
client implementations.  Wouldn't it be interesting to see Trillian 
threatened legally?  Maybe then more people would realize that AOL is the 
problem.  We should have nothing to do with them.

> The solution would be to create an XML namespace to define protocols.
> There would be a small engine built into clients to process the latest XML
> file for a given protocol.  If a protocol changes, the client automatically
> knows to get the latest XML protocol file (via JabberUpdate or something).

Sickening.  Jabber client developers should not have to deal with this.  We 
develop Jabber clients, not multi-IM clients.  Better to leave multi-IM to 
programs like Trillian / Gaim, who already contain the extra "junk" needed to 
communicate with proprietary systems.

> The client engine to parse this XML file and make remote connections would
> be open source, as well as the format of this protocol definition XML file.
> When new IM systems are released with new protocols, the client doesn't
> have to be updated - it simply downloads the new protocol definition
> automatically.

I'll address your actual question though.  I think that this spec is too 
simple.  The AIM protocol is very complicated, and probably cannot be 
represented with such a simple XML file.  Nor is each piece directly 
interchangable MSN/Yahoo/etc.  A better way would be to implement a 
clientside proxy, where the transport would tell the client to do various 
socket activities.

-Justin