[JDEV] Jabber Transports - New Architecture

[Tijl Houtbeckers]

---------- Original Message ----------

>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.

True..

>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).

This is very hard to inplement. Property-protocols do not let themselves be described 
in this way that easily.. the implemention on the clientside would be huge and 
complex, You need to anticipate things like acking, different authentication ways, 
challenge packets, etc. Do not let the sheer beauty and simplicity of the 
jabberprotocol confuse you on this one ;) 
And even then they can always come up with something new that you're XML 
description doesn't know how to handle so you'll have to update your client all over 
again. Besides that, it is against the jabber design philosophy.. what you're basically 
building then is different messengers in one, one of those being a jabber client.

A better solution for your problem would be to keep the conversion from the jabber 
XML format to the property binary formats like AIM, Yahoo, ICQ etc. on the server, 
then send this binary data back to the client either embedding it in the XML (base64?) 
wich can get a bit CPU intensive, or using XML to describe how to establish a socket 
connecion between the protocol transport (preferably one from the client to the 
protocol and not vv. to avoid firewall issues etc.). Then the client opens it's own 
connection to the property format server, and sends the binary data supplied by the 
transport to it, as well as sending any binary data is receives from the property format 
server back to transport.

This does keep complexity on the server for quite a bit, sticking with the jabber design 
philosophy, however is has some major disadvantages:
More datatraffic for the client, more socket-connections for the client, and if you use 
base64 or anything like it for encoding the binary data, more CPU power required for 
both the client and the server (though this would actually mean the server has to have 
*less* socketconnections). For a desktop client, this would be acceptable, but for 
most mobile clients it unforuntatly isn't (1 socket often is a bit too much already ;). 
You'd have to start looking at weird solutions like letting your desktop machine 
somewhere route the property protocol information for your mobile client... in the end I 
don't think it's worth going through all this trouble for a bunch of stupid companies 
that think they can lock in their customers like this, unless you just want to really piss 
off AOL in your life :)

-- 
Tijl Houtbeckers
GPRS / J2ME programmer
Druppel Internet Services,
The Netherlands