[JDEV] Theoretic.com Now Blocked

[Kevin Smathers]

On Tue, Jan 08, 2002 at 11:34:48AM -0800, Julian Fitzell wrote:
> But having each client make its own AIM connection sort of goes against 
> the whole Jabber architecture.  The whole point is that the client is 
> simple, makes one connection, and the server routes everything.  If you 
> want a client that does Jabber and AIM and ICQ by making a seperate 
> connection for each, there are other clients out there that do that - 
> but they implement the AIM and ICQ stuff in parallel to the Jabber 
> connection, not on top of it.

I agree, you could look at it as a wild departure from the architectural
goals.  But you could also look at it as if AIM were a discrete 
implementation of the Jabber server network, just as say the jabber.com
server is a discrete implementation of the server with a slightly 
different feature set from the open source implementation.  

For this viewpoint to be valid one would have to resolve two areas of
conflict however.  First the differences between the AIM and Jabber
networks is somewhat broader than the differences between jabber.com
and jabber.org.  Second, the AIM network doesn't like to interoperate
with other networks while the Jabber.com network is quite happy 
interoperating with jabber.org.

To resolve the first problem the AIM transport already maps AIM semantics
into Jabber semantics, so I think this problem is already solved.

The resolution of the second problem is somewhat trickier, but don't 
discard it just yet.  Step aside from AIM for a moment and consider 
how you would go about setting up a private Jabber network.  If you
configure your s2s connections so that they only respect connection
requests from other known servers you would have a potentially closed,
manageable network of nodes.  By locking the nodes into seperate 
logical domains you would eventually end up with something like the 
plethora of IRC networks; each disconnected from the other and refusing
to interconnect.  

My proposal was to hide the seams between networks not at the servers,
but at the client; have the client connect to each network where it 
wishes to advertise its presence and show a combined list of presences
from all networks to the user.  This would for example allow me to keep
my intranet IM network seperate from jabber.org, but still send messages
out to friends on jabber.org myself, even though the networks weren't
directly connected.

Hopefully that makes more sense... the client is perhaps a bit more 
complex, but still doesn't receive and route messages for other clients, 
so it isn't nearly as complex as the server.  Where interconnected 
networks are permissible they can be joined seamlessly without the
client being involved at all, but where they are purposely seperate,
the client can join them together for the benefit of the user who is
active on both networks.

Cheers,
-kls
-- 
          //                               .--=,
 .....::://::::::::::::::::::::::::::::.. (o O &   kevin_smathers at hp.com
:::::::://:::://://://:/:://::||_//       / V  K   
 :::::://:::://:/:|//'/' // _,|'         r ,  'qk   
  :'''/____ // /  //  |_// // ||        .'~.  .~`, 
                                   kls   \_/-=\_/