[JDEV] Here's how ICQ would work.

[Jeremie]

> - Identity strings between client and server will probably be "123412 at ICQ",
> but I don't like that. Imagine Alice giving Bob's ICQ number to Jake. Jake
> types "123412 at 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) ???

This is something I deliberated about back and forth for way too long, but
when we look at it from a "simple" user point of view, the small problems
caused by having transport names and dns names mixed together is
outweighed by the lowered technical knowledge required of the user.

If a Jabber user enters a transport-destined address for a transport that
their server doesn't have, they will get an error.  This will happen
regardless of whether it's identified separately as a transport versus a
dns address.  It is "cleaner" from a geek point of view to separate the
namespace, but as far as I can tell from every angle I've looked at it,
you don't really gain enough to merit the separation...

One last thing, the combination of the namespace can be leveraged as a
feature also, the ICQ transport could provide an alias "wwp.icq.com" so
you could send to 362345 at wwp.icq.com, or AIM could use "aol.com" and just
plugging in an AOL buddies email address will work.  There might also be
at some point a "hosts" file on the Jabber server that turns "@ICQ" into
"@pubICQ.server.com" where a public ICQ transport is running for anyone to
use instead of running it locally(perfectly feasable).

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

I'm not sure that this is something that will be in great demand, but if
the transport author wants to add support for multiple accounts, I would
think the easiest way would be to just use one as the main/default and all
the others are just "aliases" for that main one, so that incoming messages
can come in on them.

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

There are a few ways of doing that... a simple way would be have a
standard instruction at the bottom of each message saying something simple
like:
 [ Please reply appropriately to the question or with a standard ]
 [ "cancel", "home", "back"					 ]
Or, maybe in addition, at any point in the conversation the server would
prompt the user saying "I have the following information thus far, do you
want to continue, cancel, or start over?".

One last and easy way would be to make use of the <thread></thread>
feature which hasn't been described yet... I'm planning on this being used
by clients to identify new messages.  So when a user starts a new
message(ie: doesn't reply to a message) it places some possibly random or
useful bit of information in the thread tag, and when it receives a
message with a thread tag it always sends the provided thread tag back in
a reply message.  So if the user doesn't reply to the conversation but
instead starts a new message it would start the process over or maybe ask
them if they want to start over.

> 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")

I actually thought about this one at great length, and it sounds really
fun and probably easy to do, but is mostly a novelty.  BUT, with the
advent of shoutcast it could actually be useful/interesting!

> - 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 at 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 ;).

Again, I've been thinking about this quite a bit too... What about going
the "standards" route and if the web site is "jabber" enabled it is via an
<OBJECT></OBJECT> tag within the HTML defining the jabber server and
owners address etc... this way the jabber happy pages could live on any
public web page anywhere.  Non-jabber happy browsers would just ignore it,
and supporting browsers could hop onto the jabber server and fetch the
owners status or do whatever else the object tag says and display it in
the page.

I'm full of ideas, but I need to stop dreaming and start coding more :)

Jer