[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [JDEV] ICQ and AIM
qbradley@csc.UVic.CA wrote:
>
> On Thu, 14 Jan 1999, jswink@softcom.net wrote:
>
> > Welcome to jabber.server.org!
> > Available transports: Jabber AIM ICQ SMTP IRC...
> > Do you wish to use the ICQ transport? y
>
> Looks wonderful :-) It could even be a form on a web page were you apply
> for an account on a jabber server. I guess it would be up to the people
> hosting the server how exactly they get the above information.
More likely a command like client might look like the above, rather
than the server being intimately involved in conversations with
the user.
> > I'm not understanding this other transport. Does it have a single UIN
> > for its own purposes, to query the ICQ server about ICQ accounts?
> > Perhaps to send anonymous messages?
>
> No. Although that is an interesting idea. My dream ICQ transport doesn't
> do anything until I give it my ICQ name and password (in an EXT tag or
> whatever). Then it connects to ICQ on my behalf, forwarding jabber
> packets to ICQ and ICQ packets to Jabber. It sounded like you were
> proposing something exactly the same except that as soon as you connected
> with Jabber, it would create an ICQ number for you if you didn't already
> have one (or perhaps it creates an ICQ number the first time you try to
> send a message to an ICQ number).
I was, though I'm inclined to abandon that idea. Maybe each
transport requiring a password should have an option to store
it, and if not, it'd request the password from the Jabber
client when you log in. Then the client can prompt you, or
display a bright red button, or pop up a dialog, or whatever.
I still like the idea of establishing multiple nicks which
store a nickname, service, login, and possibly password, under
a Jabber account.
- User starts up client for the first time, creates account
- Client offers to set up new transports, user agrees
- Client asks server for transport list
- Server returns list
- For each transport:
-- Client asks user if they want to use it
-- User agrees
-- Client asks server for requirements on transport XYZ
-- Server asks transport XYZ for requirements
-- Transport responds
-- Server passes requirements to client [1]
-- Client gets info from user
-- Client returns info to server [2]
-- Server saves the info under that username
-- Server passes info to proper transport, for the purposes
of the current session.
Executive summary:
Each transport has setup requirements, which the client need
only examine while a user is adding a transport, and which
the server relays between the transport and client without
knowing or caring what it is.
[1] Server announces transport requirement to client
----------------------------------------------------
<transport name='ICQ'>
<field>login</field>
<field>password</field>
</transport>
<transport name='IRC'>
<field>ircnick</field>
<field>channel</field>
<field>server</field>
<field>port</field>
</transport>
<transport name='SMTP'>
<field>address</field>
</transport>
[2] Client gets info from user and replies
------------------------------------------
<alias action='add' name='Josh(ICQ)'>
<transport name='ICQ'>
<UIN>6263130</UIN>
<password>xxxxxx</password>
</transport>
</alias>
<alias action='add' name='Josh(IRC)'>
<transport name='IRC'>
<ircnick>Yath</ircnick>
<channel>Jabber</channel>
<server>irc.dal.net</server>
<port>1116</port>
</transport>
</alias>
<alias action='add' name='Josh(email)'>
<transport name='SMTP'>
<address>jswink@softcom.net</address>
</transport>
</alias>
--------------------------------------
In this scenario, the server knows nothing
about the specific info that a transport needs,
just passing messages between a transport and
a client. The client parses the description
of what's needed, gets info from the user, and
then forgets anything it ever knew about the
transport.
It could also be fun to allow a bit more complexity
in the <service> messages, so you could indicate a
number of IRC servers with priorities, to say which
one gets tried first, and a number of channels to
join.
<transport name='IRC'>
<field type='alpha'>
<description>IRC nickname</description>
ircnick
</field>
<field copymin='1' copymax='10'>
<description>Server name</description>
server
<field type='inet_address'>address</field>
<field type='integer' minimum='1' maximum='65535'>port</field>
<field type='integer' copymin='0'>priority</field>
</field>
<field type='alpha' copymin='1' copymax='10'>
channel
</field>
</transport>
Early client prototypes could easily ignore much of
the markup and still work.
<alias action='add' name='Josh(IRC)'>
<transport name='IRC'>
<ircnick>Yath</ircnick>
<server>
Dalnet
<address>irc.dal.net</address>
<port>1116</port>
<priority>10</priority>
</server>
<server>
Imaginary IRC server
<address>irc.imaginary.net</address>
<port>1116</port>
<priority>5</priority>
</server>
<channel>Jabber</channel>
<channel>Hottub</channel>
</transport>
</alias>
> However, it makes perfect sense for each Jabber server to have an ICQ
> transport configured with its own ICQ number. Jabber messages to ICQ
> numbers from people who have not yet logged in would be sent through this
> number.
>
> The problem with this is how does the Jabber ICQ transport know who to
> send messages back to recieved from ICQ to this "anonymous" ICQ number? I
> don't know the ICQ protocol, but it seems like it would need to support a
> way of sending an identifier of some kind in the message that was
> guaranteed to be sent back on the reply. I doubt this is possible, so
> anonymous ICQ probably could only be one direction.
Probably not worth doing.
Joshua Swink
jswink@softcom.net