[JDEV] Re: comments...

[David Jeske <jeske@home.chat.net>]

On Tue, Jan 05, 1999 at 03:44:05AM -0600, Jeremie Miller wrote:
> > 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.

I think AIM and ICQ users can already talk to eachtoerh because the
server's communicate, I would think it worthwhile to talk to them
about collaborating to let the servers talk and prevent this
duplication of IDs. Is this what that standard is trying to do?

> 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@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 still don't undertand why you think "user@host" is a step
forwards. One of the best things about ICQ IDs is that no matter what
your ISP is that week, or where you're connected from you always have
the same number. Email should be more like email, not the other way
around. None of the functionality you propose above requires user@host
style addressing, yet by using it, I'm going to have to tell people my
new hostname if I switch ISPs. So in my mind, you are definetly
_losing_ functionality there.

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

This is a reaon to allow client->server->client connections not a
justification for not allowing client->client connections.

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

Again, this isn't a reason to disallow client->client connections,
it's instead a justification for allowing client->server->client
connections. (i.e. if a client is not capable of direct connections,
then you can require both sides go through the server)

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

This is the only reason you've specified which IMO actually needs to
dictate 'no client to client communication'. However, there are cases
where the benefits of client->client outweigh the security risks,
particularly when you are dealing with a friend of yours who is in
your contact list.

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

It does not. It may require that some connections go through the
server. However, just because some connections have to go through the
server does not mean other could be direct client->client.

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

I'll give you a few reasons which support the idea of direct client to
client communication:

1. bandwidth
2. bandwidth
3. bandwidth

  If I'm transfering a file with another client, and you require 
  client->server->client connections then, (a) the servers I'm going through
  are going to have to have enough bandwidth to support me, and (b) 
  my transfer speeds are going to be limited by the paths to and from the
  servers, and the paths between servers.

4. simplicity... instead of having to install servers on tons of ISPs, if
    you have client to client communication, then you essentially make clients
    their own servers. No need to get a huge installed based of servers
    before you stop wasting bandwidth.

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

But then your jabber stuff is _not_ always client->server->client, and
the webpage information is wrong. Of course the control connection
will be client->server, why would you do it some other way?

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

Uhm... then why do you say that there are no direct client->client
connections?


-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net