[JDEV] MIME, was My evil plans for a client.

[Thomas D. Charron]

>This sort of brings me back to my peer-peer question.  File transfer is 
>really a high bandwidth, client-side, endpoint-endpoint operation.  There 
>really is no reason it needs to go through the server right?

  Wrong..  Jabber's modularity in is the way it can route the data from point A to point B.  One client can be anything, and another can be something completely different..   Example:  167289 at mobilecomm.jabber.org would be a pager number.  someone.someaddy at smtptransport.jabber.org could be someone mailbox..  That is also one of the reasons for JNX existing..

> Everybody 
>else shouldn't be loaded down when somebody sends their video files to 
>each other.  So, is there any reason against allowing (even requiring) 
>clients to set up their own peer-peer connections for this type of activity?>

  This is the hurdle we need to decide on..  How to
transfer data..  So far the best I've heard so far
is using HTTP for file transfers.  This would also
allow many current streaming technologies to be used
by jabber, in the same way that a browser currently
does.

>The only issue I can see is security.  Were there any plans on 
>introducing security to Jabber?  If not, what else is preventing 
>client-client connections.  If so, can't it then be extended to 
>client-client?

  Nothing is preventing someone from creating a peer to peer connection.  But, once again, we need feature
negotionation.  In the meantime, anyone could plunk
in some sort of peer to peer networking.  I'd just
advise anyone looking at it try to stick to the
standard Jabber protocols, but merely allow them to go
direct to the client.

> I have always seen the messaging "server" as simply a 
>router, or DNS server.  Once you know "where" your buddies are, you can 
>talk to them directly instead of going through the server.  This 
>increases messaging speed and unburdens the server.  

  That's one way to look at it, but Jabber's power is
in the fact that it ISN'T just a 'Buddy is Online'
system.  It's a way to route data from point A to
point B in a extendable manner.  That's what the transports
do.  In this, the server DOES DO MORE.  This is not a bug, it's a feature..

> In my view, the 
>messaging server should really be an event notification server (buddy is 
>online, buddy is offline, buddy moved here, etc.).  This doesn't really 
>burden the client, since the protocol for client-server is the same as 
>for client-client.

  Then use the server to relay this data, and implement
a client to client protocol.  Easy enough..  I tend
to think that this ends up ruining the point, as you
are now locked thru a comm channel, and can't automagically
route packets somewhere else, without doing some sort of
hack..

  It's all a pmatter of opinion, I guess.  I'm not trying to put your down, I just happen not to like it..

---
Thomas Charron




--== Sent via Deja.com http://www.deja.com/ ==--
Share what you know. Learn what you don't.