[JDEV] ICQ/AIM, ID's, and Transports

[Jeremie]

Sorry I haven't been able to follow/respond to the thread(s) in a timely
manner, a combination of (paying) work and the flu cause all kinds of
problems.

Alrighty then, I'll try to summarize my thoughts on the whole transports,
ID's, and their setup/config issues.  It looks like many of the comments
thus far are real close to what I was thinking, which is great!

For a Transport to allow transparent communication to other systems, it
will need to act as a client to those systems for the Jabber user, and
this will require a valid ID/pass on that system.  I'm expecting that this
ID will be either provided to the transport when the Jabber user
configures that transport for their use, or a new one will be created for
them at that time.  [Providing your existing, say, ICQ ID#/pass would
allow you to use Jabber as an instant drop in replacement for ICQ w/o your
ICQ buddies even noticing since you haven't changed from their point of
view, VERY handy!]

So a Jabber user cannot use a transport until they have setup/configured
that transport directly.  I've always intended this to happen via two
means, the web and via messages.  It can be very powerful to provide
web-based configuration for all aspects of Jabber, the transports,
modules, account creation, message history/searching, and directly with a
web-based Jabber client[all my web ideas I'll save for another day].  So
obviously configuring the new transport might be as simple as filling out
a form on a web site.  BUT, *importantly*, many people want something
simpler and don't want to rely on a web browser at all, and we can't
expect a client to provide ways of configuring every transport, and we
cant create a "standard" way of communicating this information since it's
very dependant on the transport(we'd end up re-creating HTML forms) and we
can't predict future transports.  What to do for the non-web based one
then?  Again, the answer is simple although it requires a bit more
programming work.  Every transport has a standard set of
addresses(including the Jabber transport) and they might be: info, help,
and register.  The register at TRANSPORT or register at server.com would reply
right away with instructions(and a URL for the web based form), and the
Jabber user could reply with the needed info and a little conversation
could ensue to finalize the configuration.

Simple example of possible conversation:

	Juser->register at ICQ : "How do I register?"
	register at ICQ->Juser : "Do you already have an ICQ account?"
	Juser->register at ICQ : "yes"
	register at ICQ->Juser : "What is your ID number?"
	Juser->register at ICQ : "2346345"
	register at ICQ->Juser : "What is your password?"
	etc...


Few things to note, for many transports there will be no way to
communicate with the Jabber user unless they have configured the transport
ahead of time(like with ICQ/AIM) but this really depends on the transport
and limitations of the system it is talking to.  It should also be
possible to have multiple registrations per transport, but this is really
an issue the transport author would deal with.

This is of course all just my opinion/thoughts on transports when I was
designing Jabber... improvements/corrections/comments welcome :)

Jer