[JDEV] Here's how ICQ would work.

[Dan DeMaggio <dmag@umich.edu>]

Jeremie Miller wrote:
> If it so happens that one of those ICQ users also uses Jabber, there
> is nothing in any way being done to associate that. 

Let me expand on that:

Say Alice and Bob both have ICQ accounts, and are on eachother's ICQ buddy
lists. Alice switches to Jabber (and her server supports ICQ). Alice stops
using her ICQ client. When Alice logs into Jabber, her jabber server logs
into ICQ on her behalf.  When Alice (using jabber) sends a message to Bob,
her server sends an ICQ message from her ICQ account. Alice is using ICQ
via remote-control! Bob won't ever suspect that Alice has switched to
Jabber.

Jake, another jabber user, doesn't have and ICQ account or an ICQ-enabled
server. Jake can now talk to Alice via jabber, but he can't talk to Bob.
Jake doesn't care, since he's lived his life up to this point without
getting an ICQ account. ;)

Later, Bob gets Jabber (on an ICQ-enabled server). When Bob logs into
jabber, his server logs into ICQ on his behalf. Bob can still see Alice
thru ICQ, and they can send messages back and forth. Alice and Bob see
eachother on their jabber buddies list, even though it's really their ICQ
buddies list. Alice and Bob can go on like this forever without realizing
they both have jabber. When Alice sends a message, it goes like this:

Alice client --> Alice's jabber server -> ICQ transport --> 
ICQ servers --> ICQ transport -> Bob's jabber server --> Bob's client

In fact, Bob and Alice could be on the SAME jabber server, and still not
know it. Sure it's inefficient, but I don't see any way to detect jabber on
either end without being intrusive. ("This message brought to you by
Jabber(TM), the new XML-enabled personal messaging protocol for good little
boys and girls!")

Later, Alice mentions her jabber address, and Bob adds her as a jabber
buddy. Whenever Alice logs in, two entries appear on Bob's list: One for
jabber, and one for ICQ. Bob knows it's the same person so he takes Alice
off his ICQ Buddy list. Problem solved. Alice has to do the same thing too.

[Side note: we could write lots of code to try and detect this, but I don't
think it's needed. Besides, mabye Bob doesn't know that his friend
Alice@alice.org is the same person as his friend "DarkAvenger" on ICQ. Why
spoil it? ]

That's how it should work. Here's my implementation thoughts:

- Adding/removing buddies from the ICQ list should be do-able from the
client, as normal jabber add/removes. The client must have *NO* code to
support ICQ, and the transport must do all the work of translation.

- Rosters are stored at the server, since I don't want to re-type my buddy
list if I borrow a random computer.

- Jake (who doesn't have ICQ) can't talk to ICQ users. Before he got
jabber, he didn't have an ICQ account. Why should he "suddenly" want one
now? Let's face it: Jake doesn't care about ICQ users. Or AIM users. He
uses jabber because his friends are reachable thru jabber. [ Therefore, the
"ICQ account creation" feature of the ICQ transport is not important enough
for Version 1.0. It could always be added later. In the mean time, people
could get their ICQ account the old-fashioned way :]

- Identity strings between client and server will probably be "123412@ICQ",
but I don't like that. Imagine Alice giving Bob's ICQ number to Jake. Jake
types "123412@ICQ" but his server doesn't have an ICQ transport. His server
will assume that ICQ is another server and try to contact it. Even if a
computer named 'icq' doesn't exist, Jake's server is confused. Yuck. IMHO,
there should be some special way to identify transports vs. computer names.
I don't like requiring a period in the server name because there are many
intranets (and Micro$oft networks) without name servers or connections to
the internet. All computers are known on a first-name only basis. Maybe a
slash (123/ICQ) or a pound-sign (123#ICQ) or combo (1234@#ICQ) ???

- Handling multiple ICQ accounts is going to be tricky. If alice has 2 ICQ
accounts (one for DarkAvenger and one for Alice), and she sends a message
to a random ICQ user, how does she specify which ICQ account to send out
on? If the user is on her buddy list, she can indicate her preference once,
and everything will be cool. There is still the question of how to name the
transports: "1234@ICQ.DarkAvenger" ? ? ?

[ The client/server division would suggest that the prefrences be stored on
the server, so the client only sends it to 1234@ICQ, and the server figures
it out. But if the server doesn't know your prefrences for a particular
user, then how would it ask the client for the new prefrence? Shesh, this
is giving me a headache. ]

- Billy (who only has ICQ) can only message jabber users who have ICQ
accounts. But he doesn't know them as 'jabber users', only ICQ users. Billy
cannot talk to Jake and vice-versa. They couldn't before jabber, but we're
not here to solve the world's problems. :)

Everything I said for ICQ also applies to: e-mail, 2-way pagers, PGPJabber,
AIM, and smoke signals. None of these protocols should appear anywhere in
the client source code. (well, except encryption). The point is to be able
to add these protocols (on the fly) at the server ONLY. As far as the
client is concerned, roster names are just arbitrary strings that the
server makes up.

-=Dan=-

P.S. I like the "conversation" idea for configuring jabber transports ;)
but I don't think it has enough 'navagation ability'. What if the user
wants to start over? what if they want to skip a section that they've
already configured?  At least with touch-tones, you've got the # and *
keys.

P.P.S. Brainstorming new jabber transports (or client features)
- WinPopup messages (M$ networking) - Totally do-able via Samba.
- IVR (Computer calls you up and reads your message.)
- WinAmp messages (dmag is now playing "CJ Bolland - Sugar is Sweeter")
- X10 - remote control lights and stuff.
- Web 'presence' support (see who's on a web page..). Modify NetScrape to
send http header "X-Jabber: alice@alice.org", and server will add an
"X-Jabber" header with a list of jabber users to who recently visited that
page. It could work ;).