[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Jeremie wrote:
> 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. 

But most potential users (especially cable modem users) don't have control
over their DNS and can't spare an extra IP address. Adding "Remote
Transport" functionality is easy in XML (<to
transport='ICQ'>999@alice.org</to>.)  The question is how to represent the
transport + extra user info in the UI or on the command line for sending a
message.

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

There's nothing illegal about ICQ or AIM as host names. I don't mind
reserving one or two names like that, but there are potentially an
unlimited number of transports that people will write. People will have
transports like MAIL and PAGER and AUTOREPLY. 

I think rosters should be portable between users on different servers. (as
in "let's see your roster file") 

The problem I have is that the 'transport names' file will be local to each
server. It would be like /etc/services: You won't be able to rely on it.
It's supposed to be a central config file, but on a network it's a bunch of
isolated config files that never get updated. Applications are forced to
use port=80 because http may not be in your services file. The other
problem is that storing the file is extra work. Since not all users want
@ICQ to go to the same place, each one would have to setup their preferred
@ICQ server. And the server would have to store that somewhere. With the
'transport=ICQ' option, the server doesn't need a magic mapping table.
People can put ICQ users directly into their roster. (the roster stores the
transport along with the name).

The only strange thing is that some transports will be 'different' from the
users on the server. For example, the first one doesn't involve our user
alice, but the last 2 do.

<to transport='AIM'>    Alice@alice.org </to>
<to transport='Jabber'> Alice@alice.org </to>
<to transport='PAGER'>  Alice@alice.org </to>

As far as how to represent the above as a single string, I'd say it's up to
the client. Maybe one does "jsend -t AIM alice@alice.org" and another does
"alice@alice.org/AIM". And graphical UIs may be completely different (but
we have to watch out, the above shows how easy it is to send to the wrong
user)

In fact, maybe there should be 2 types of transports: remapping transports
and normal transports. That way, we don't confuse the AIM user Alice with
the jabber user Alice. ? ? Hmmmm, this is getting complicated..

-=Dan=-