Re: [JDEV] Here's how ICQ would work.

[Jeremie <jeremie@jabber.org>]

> I like the idea of 'distributed' transports (i.e. my server doesn't support
> pagers, so I offload that to somebody else.) My thoughts:

So do I, it's always been part of the model Jabber is working towards.

> 
> - Clients should connect to their 'home' server only. Remember, they may be
> behind a firewall, etc. This keeps the client simple.

Yup.

> - Imagine getting a jabber account at public.org, then later, your work
> sets up a jabber server and gives you an account.  You don't want to check
> both, so you could have your work jabber account forward to your original
> account.  There are some strange issues, like how does the client know I
> can send a message from "dmag@work.com" even though I'm connected to
> public.org?

Well, I guess I consider whatever server you are currently connected to as
your base server and all outgoing messages from that connection are from
that base server.  You should be able to easily configure any other server
that you have an account on to forward messages to your base server.

There are quite a few hairy issues that can creep in here in relation to
multiple accounts across multiple servers, and honestly I'd like to leave
most of this for a V2 thing, keeping V1(the first real public distro)
functional but simple and building on it from there with many of the less
popular but still important features like this, just MHO of course.

> - There are 2 ways to handle a distributed transport: 1) Server-Server
> communication 2) Client-Server communication (a transport on my home server
> pretends to be a 'client' and logs into the remote server.). I'm not sure
> which is better. #2 looks like it wouldn't require any modifications to the
> protocol. But #1 would be more elegant.

Actually, #1 is exactly how it works and it can already work that way!
All you have to do is configure the transport to identify itself as a real
DNS name "publicicq.server.com" and anyone in the world can connect to it
via 346234@publicicq.server.com easily :)

> - I like the "@ICQ" -> "@pubICQ.server.com", but how does pubICQ.server.com
> know which transport it's supposed to route the message to? And how does
> one configure the mappings? Especially since this looks like it needs to be
> a per-user configuration to me.

Oh, ok, yes... this is where the JabberBox steps in.  Since the JabberBox
recieves all incoming/outgoing messages for any server, the ICQ transport
on that server just needs to send it's DNS alias to the JabberBox when it
starts up:

JabberBox Running
ICQ Transport starts
ICQ Transport sends local JabberBox <alias>pubicq.server.com</alias>
JabberBox accepts incoming packets and routes them to the ICQ transport

Actually, this is one of the most important features of even having the
JabberBox, local "virtual host" transport name resolution/routing, all
transparently to the other servers and local transports.

> - The clients might want to know the above mappings, so they can have a
> pull-down listbox when sending a message.

This is something I think a little real world testing might help us find
out... maybe we can better answer it after we are all using Jabber daily
:)

> Maybe we could do a URL like scheme like this:
> 
> - icq:9999
> - icq:9999@pubicq.server.com
> - save:dmag@server.org
> [etc comments compressed]

Well, again, I think the already simple scheme is built to handle all of
these, just using regular DNS names or transport names... the user id is
on the left of the "@" and the right side represents either a local
transport(typically uppercase one word) like ICQ or AIM or JABBER, a dns
name(which can ALSO be local) like myserver.com or icq.myserver.com, or a
remote dns name which maps to an IP of the JabberBox but the actual dns
name maps to a transport within that JabberBox.  

To simplify, the "server" address on the right is really the actual name
of a transport, but the resolved IP for that name is the real "server" 
that the named transport lives on.  All names are checked on the local
JabberBox first which lets you get away with non-legal DNS names like
"ICQ" or "AIM" for shorthand aliases to those transports.

Make sense?

Jer