[JDEV] Just an idea...

[Dave Smith]

Hey Rob...

This has come up quite a few times over the evolution of the Jabber project. :)
One of the original design goals of the Jabber project was to support IM
across firewalls. Frankly, client-client connections don't fit into that design
goal -- and never will, probably.

That said, I would be remiss to not say that it's perfectly 
possible to write some add-on modules for the server that would provide this kind 
of functionality. The reason the Jabber project hasn't pursued this is because
we feel it's outside (way, way outside) the scope of the project and the 
complexity it adds is not worth the investment in time.

Jabber was designed to be server-centric from the beginning. Writing extensions
that add client-client functionality will wind up being "hackish" and are better
left to architectures which were designed with different goals in mind.

D.

On Thu, Aug 31, 2000 at 12:14:07PM -0700, Rob Brown wrote:
> Please forgive me if this is a rehashing of things that have already been 
> discussed.
> 
> I am curious if anyone has considered having an "extended" protocol for 
> clients, where clients can reduce load on the server and provide extended 
> functionality, by becoming "listening" servers themselves.  The idea being 
> that clients do not have to support this, but ones that do will identify 
> themselves as such and the server (which also doesn't have to support it) 
> can use it if it wants to.
> 
> The two things this might be useful for are:
> 
> 1.  allows the client and/or server to close the connection while still 
> maintaining "presense", probably allowing the server to scale better 
> because it doesn't need a persistent connection for every person.  If an 
> event happens, the server knows how to contact the client because it 
> maintains its address.  This would be transparent to the users: from their 
> point of view, they never have to know when a connection is open or not, 
> they simply have enabled a setting which allows the server (or the client) 
> to decide when it is appropriate to close the connection.  Presumably it 
> would close the connection if it's inactive for a period of time.
> 
> 2.  allow trusted members of your buddy-list to connect directly to your 
> machine.  The user could allow some or all of the people on his list to 
> directly communicate peer-to-peer if they also support the extended 
> protocol.  If they don't support it, or they don't wish to connect peer to 
> peer with you, it falls back on the current behavior.
> 
> I would imagine that if you can connect peer to peer with another client, 
> there are things you could do that would otherwise put too much load on the 
> server...sending files/voice chat/etc.  I always liked ICQ's "continuous" 
> chat mode (where characters show up as you type them), but even that might 
> put a lot of strain on the server since it is so inefficient.  If you are 
> connected peer-to-peer, who cares?
> 
> This seems to address most if not all of the reasons I have seen given for 
> the Jabber approach of "everything goes through the server".  Messages to 
> people on other systems (ICQ etc) would still go through the server of 
> course, and the client can still be ultra-simple if it doesn't want to 
> bother supporting this protocol.
> 
> Has anything like this been discussed?  Already been soundly rejected? :)
> 
> -rob
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20000831/1e95cce9/attachment-0002.pgp>