[jdev] another concept of ICQ transport

[maqi at jabberstudio.org]

On Tue, 17 Aug 2004, Alexey Nezhdanov wrote:

> jabber server that supports not only in-band or web administration, but
> allows users to log in using their ICQ UIN and password. So - it will be
> straight forward way for migration - just supply your credentials and
> you will got your contact list immidiatedly just if you were logged by
> some alternative client.

Actually, I think this is a client thing: Users can't use the AOL ICQ
client for this anyways, so the steps that have to be performed are
- user starts Jabber client
- user enters ICQ credentials
- client sees "oh, this is an ICQ user" and prompts for additional info
(Jabber user name...)
- client registers new Jabber account and adds ICQ gateway

So the thing you propose can be achieved by adding a kind of wizard to
whatever Jabber client you like.

> The backside is that we will get a zillions of badly named jids and
> worstly that the user can imagine that jabber is just some another
> client for ICQ.

Yes. That's why I wouldn't propose anything more than a wizard, if at all.
Probably, for most people a multi-network client such as Gaim or Trillian
is even better suited as these clients provide better ICQ support than JIT
or AIM-t do.

BTW this is an opportunity the Trillian and Gaim programmers are utterly
neglecting for ages now: Imagine the multi-IM client not merely being a
slave for the legacy IM networks, coming into the user's view mostly if
they need to be updated *again* because a legacy network changed protocol
once more. Imagine the client more or less aggressively promoting an "own"
network: "Hey, I'm Trillian, please register an account on trillian.cc and
you'll be able to chat with your Trillian friends regardless whether the
legacy networks have gone crazy or not" (of course, in the background this
is really a Jabber server running at trillian.cc ;-). Pros: In the long
run, people will stay with the network and probably the client AND there
could be all kinds of nifty features included in the client such as
message histories stored on the server, client settings stored on the
server and so on.

However, it looks like most multi-network clients are just lacking the
background and perhaps manpower to implement such a thing :-(.

Regards