[jdev] Resource binding

[chris]

On Mon, 1 Mar 2010 14:01:18 +0000, Dave Cridland wrote:
> On Mon Mar 1 13:21:41 2010, chris wrote:
>> Anyway, my use case for this is generalized as such, and is not IM 
>> related:
>> 
>> An internet connected client exists for node at example.com, this 
>> client is the interface to many non internet enabled clients which 
>> are identified by resources node at example.com/x1,x2..xn, where n 
>> could be a fairly large number.  As x1..xn are all associated in a 
>> particular way for this use case, it makes sense (for reasons not 
>> here explained) that they are connected using a single bare JID, 
>> besides the fact that maintaining many streams/connections is 
>> certainly not ideal and even problematic.
> 
> But you're likely to be running your own extension anyway to talk to 
> these things, so you could make your XMPP client handle the routing 
> in other ways than try to break the 1:1 relationship between 
> connections and resources.

Not quite true... Although I did say this was not IM related, I am 
using XMPP for the core functionality it was built around, namely 
presence and messaging (along with custom extensions) with the 
expectation of being interoperable at a basic level with the 
federated XMPP network.

So, if they are not exposed as a resource then they can not appear as 
a resource to the rest of the network. ie one can no longer naturally 
add them to the roster, get presence information, send messages etc. 
Any generic XMPP client loses the ability to interact with them at 
all.  Only a custom client implementing the necessary extensions are 
able interact with them.  Not very interesting.

You allude that a 1:1 relationship between a connection and resource 
is desirable; I don't see why that should be so.  A 1:1 relationship 
between a connection and a stream, ok.  But I see no specification 
level need to limit the number of resources bound to a stream let 
alone, either implicitly or explicitly, to a connection.

> For instance, XEP-0030 encapsulates individually addressable objects 
> within a client perfectly well without introducing multiple 
> resources on a single connection.

What XEP-0030 does provide is a way to discover an XMPP entity's 
features, extensions, resources et al. as well as enumerate a 
client's *non* addressable items; this is most useful in its own 
regard.  However, I do not see how this is meaningful as a 
replacement or alternative to binding multiple resources to a single 
stream, nor negating the need for it.

I don't believe this discussion is about discovery, and XEP-0030 
provides nothing for accessing non-addressable 'items' as normal XMPP 
resources - ie, basic presence and messaging capabilities, let alone 
any other commonly implemented client functionality.

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.

regards,

chris

 		 	   		  
_________________________________________________________________
Hotmail: Powerful Free email with security by Microsoft.
http://clk.atdmt.com/GBL/go/201469230/direct/01/