[JDEV] Jabber Transports - New Architecture

[Julian Missig]

One of Jabber's main goals is not interoperation with closed protocols
who want us out. Among Jabber's main goals are simplicity of client
implementations and firewall awareness. Your proposal would require
firewalls to open all ports for all IM systems, and simplicity of
clients is completely gone, assuming it is actually possible to describe
the protocols in the fashion you want.

The transports were created to ease the transition to Jabber. If the
closed IM world wants us out, I'm certainly not wasting my time and
effort on hacking around every way they find to keep us out. I think
it's more worth my time to improve Jabber.

Julian


On Thu, 2002-03-07 at 18:20, Lake Clear wrote:
> Hello,
> 
> 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.
> 
> I've been thinking of a solution to this IM interop problem and came up with
> a solution - I want to run it by this group to see how viable it would be.
> Or perhaps someone already had this idea and can point me to the right place
> =)
> 
> 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.
> 
> 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).
> 
> For instance, an XML file would look something like this:
> 
> <PROTOCOL name="AIM" ip="1.2.3.4" port="1234" >
>    <LOGIN   - info on how to login, including field lengths, values, etc...
> >
>    <ROSTER  - info on what the incoming roster looks like ...>
>    <ADDBUDDY - info on how to assemble an "add buddy" packet  >
>    <INCOMINGMSG - info on what an incoming message packet looks like  >
>    etc....
> </PROTOCOL>
> 
> The client would read this file to determine how to parse incoming packets
> or streams, and how to write outgoing packets or streams.  If AOL decided to
> alter the protocol a little to throw us off, someone would simply update
> this XML protocol file, and it would be instantly available to all clients
> accessing a Jabber server, via Jabber Update or some other automated
> mechanism.
> 
> 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.
> 
> If something like this exists, let me know!  If not lets make it part of
> Jabber.
> 
> Mark