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 n...@example.com, this
>> client is the interface to many non internet enabled clients which
>> are identified by resources n...@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/
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: jdev-unsubscr...@jabber.org
_______________________________________________
