comments...

[Jeremie Miller]

> 
> Connection with ICQ and AIM: How do you intend to handle this?

Two ways, either by storing an already existing ICQ # and password, or
creating them when the Jabber user doesn't have one available.  The ICQ
transport then just maintains connections for those users that communicate
to other ICQ users.

> ID: Having user's identified _at a server_ is a step backwards. Even
> since the early unix days, there has been a program called "talk"
> which lets you talk to a user on anohter unix host, however you had to
> know the server name. The great big win of ICQ/AIM is that you can be
> connected from anywhere. I agree that it's frustrating that ICQ dosn't
> let you connect from multiple machines, but the solution (IMO) is to
> let you connect from multiple machines and let the chat requests be
> displayed in ALL locations, so you can 'pick it up' wherever you are.

Actually, Jabber is a sudo situation of both, and hopefully picks up the
best parts of both.  The server is intended to be run at the ISP level
similiar to email, news, imap, etc.  Users are identified just like in
talk or email, as userid at jabberserver.com.  And above it all, they can be
connected from multiple machines multiple times under the same account,
and each connection can be uniquely identified/addressed with a nickname,
or messages can be broadcast to all of them and you can pick it up
anywhere.

I tried to design the best of both worlds into Jabber since I use both of
them regularly, and Jabber was written to make my life easier :)

> No central server: even if you don't want to have a central server
> which routs information, you should have a central meta-server which
> keeps track of other servers.

Exactly, and this is definately planned... I just wanted to get a working
server before I took that step.

> No direct client to client connections: Why? 

Lots of reasons, and I doubt I can remember them all, but I agonized over
this for some time... I'll try my best to remember:

1: Firewalls
	The majority of firewalls allow outgoing TCP connections with
little or no effort or major security risks.  Easy enough if thats all a
client does.

2: Simple Clients
	It's far easier in so many situations to write a simple client
that only has to connect and send/recieve data.  Heck, you could even
write a dumb client as a shell script this way :)  Simple ubiquitous
clients everywhere is important.

3: Security
	No IP's, etc...

4: Importantly, Jabber is designed to work transparently with any other
instant communications medium, and that pretty much rules out any easy
client<->client connections since the other clients are unknown.

4: There are a bunch more, but I'm running out of steam for today and
can't think straight... 

The other big things to keep in mind here are that files and other big
data chunks will not be traveling over this client->server connection, it
will only contain status updates, roster lists, and messages.  It's mostly
just a control connection at this point.

Also, there is no reason a Jabber client can't use the main client->server
connection to pass information with another client, and start up it's own
direct connection to it and do whatever it wants :)  In this case, Jabber
just acts as the "DNS" of the application.


Jer