[jdev] Resource binding
jugg at hotmail.com
Wed Mar 3 22:18:31 CST 2010
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
> 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
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.
Hotmail: Free, trusted and rich email service.
More information about the JDev