[jdev] Resource binding

[chris]

On Wed, 3 Mar 2010 15:14:15 +0000, Dave Cridland wrote:
> On Wed Mar  3 14:18:45 2010, chris wrote:
>> So, I am not certain what you meant by "individually addressable
>> objects within a client" in the context of XEP-0030 as applied to a
>> client JID.  I would appreciate some clarifications on that
>> statement.
>
> Pubsub nodes, for instance, are addressable (ie, you can send stuff
> to them) but they share a single jid. This happens not to be within a
> client, but there's plenty of examples of XEP-0030 nodes being used
> for addressing.

For a client, XEP-0030 nodes aren't helpful as they aren't addressable.

In any case, if multiplexing resource bindings do not become standard, 
I've intended to use XEP-0163 for a stripped down feature set, and 
expose the rest via custom extensions.  But I believe that approach 
greatly reduces the usefulness of this system.

> If you want your objects to appear as being individually addable to
> rosters, etc, then you do have a problem, but the solution is really
> to use multiple connections, since you'll find it extremely difficult
> to add full jids (ie, ones with a resource) to rosters with most
> clients anyway.

I'm sorry to hear that... I guess I haven't tested enough clients, but 
the few I have, allowed full JIDs to be added to the roster, per the 
specification, just fine.

> Of course, you could always use the component protocol, which *will*
> give you multiple jids within a domain on a single connection, which
> you can then process how you want.

Component protocols require associated DNS entries.  They also require 
connection to a specific server that is configured to accept the 
connection.  Unfortunately, neither restriction is acceptable for my 
requirements.

Simply put, XMPP only provides the notion of client entities that do not 
require custom server implementations in order to connect to the network.

I still haven't read any reasonable argument against multiplexed resource 
binding.  The two main points made are "it complicates the protocol" and 
"for what purpose".

To the first point, it was a very simple change to the protocol in my 
perception and OPTIONAL (unfortunately) at that.

To the second point I think this and other threads have answered that 
question, but essentially it boils down to allowing the only type of XMPP 
entity, a client, that does not require DNS and custom server support to 
be something besides an instant messenger or a one off implementation 
that is only useful within its own network.

chris

 		 	   		  
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/201469228/direct/01/