Re: [JDEV] Re: comments...

[Jeremie Miller <jeremie@netins.net>]

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

I don't believe that AIM and ICQ users can currently talk to each other,
at least I haven't heard anything about it nor has anyone else that I've
ever talked to...

I'm not too worried about the duplication of ID's, for existing ICQ or AIM
users moving to Jabber, they can use their existing accounts with those
services, for new ones, a new ID can be created for them that the server
can maintain.

Pure transparency is what I'm going for here...

> Is this what that standard is trying to do?

Which standard?  The IETF one or the Jabber protocol?  Either way, no, I
don't think so, unless I am very confused about what you are
asking/saying.

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

The user@host is the only way to get around a public directory or central
server like ICQ/AIM, the user needs to be addressed based on the server
they use, simple as that.

And we are _not_ losing functionality for the simple reason that we can
solve this problem EASILY just like email has... anyone can write a simple
transport for Jabber that does nothing but hook into a DB backend, and
forward messages/etc to the real ID... just a big forwarding server, and
run it at jabber.org or anywhere that you might want a vanity jabber
address.  You'd just maintain your "current" address wherever you are
currently at.  No big deal.

> This is a reaon to allow client->server->client connections not a
> justification for not allowing client->client connections.
>
> [other similar comments smooshed]

I haven't disallowed client->client communications, it's just that those
communications aren't really "jabber" at this point, it would be whatever
those clients are doing.  Jabber is just the server and communications
with the server, the clients just speak it when they talk to the server,
there is no reason that they can't do whatever they want when talking to
each other, and use Jabber to communicate their IP's, ports, etc to each
other to set up the direct communication.  In fact, a game could use
Jabber to do exactly that :)

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

Right now, Jabber is only instant messages,  roster lists, and status
updates... all tiny text chunks, no bandwitdth problems there.

File transfers are a different story, but I haven't said anything about
those just yet, and I'm not going to argue they they have to go through
the server except when they have to(to another transport).

Actually, if possible, I'd like to see all file transfers happen using
WebDAV or a small subset of it(It's just fancy HTTP/1.1 plus other stuff)
and suggest that clients try implimenting a small HTTP server just to
recieve files directly from other clients, but it will not be a
requirement and they can go through the server if needed... exactly what
you're saying I think :)

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

Exactly!  *grin*

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

Because there currently aren't any... and for whats working right now and
in the near future, there doesn't necessarily need to be except for file
transfers.

Jer