Ok,
but a URI is implied when you create a node, so it exists in some
form regardless. If you dont want to specify a URI per node, then what
about adding a server attribute/element in the xml somewhere for the
collection management requests instead? I think this is really important
for xmpp and would provide real interoperability between services. Why
shouldnt I be able to create a node somewhere that effectively
aggregates any other nodes data and/or events? Limiting everything to
one machine just seems weird in a distributed system. What options does
it leave for scaling to millions of nodes?
I also think the "its difficult for implementors" argument is flawed
since if the server implementors dont provide it, then the end users are
forced to come up with their own workarounds, or worse choose another
solution altogether. I would have thought raising pubsub events and
listening to them either local or remote would be exactly what xmpp
should be great at (users already subscribe and listen to the raised
events, why not other nodes?), and should not represent a complicated
implementation.
"reflecting pubsub from remotes into your local service through some
means" sounds like a huge hack, would likely be slow, and is what I want
to avoid.
I'm looking for an alternative to clustering service implementations in
XMPP.
I sincerely hope this group considers ammending this xep.
Cheers.
Brian Cully wrote:
On Jul 29, 2009, at 18:58, Jason <[email protected]> wrote:
This is a repost, I'm still hoping for a response.
Re "XEP-0248: PubSub Collection Nodes",
It appears that there is no support for pubsub collections to contain
remote nodes. I would like to be able to create a pubsub collection on
a server, and add nodes from other servers to it).
I'm wondering why this is?
Because collection nodes and child nodes do not use a URI as parameters.
Instead they reference node names directly which are only unique to a
given service.
The rationale is likely because of the difficulty for server
implementors in dealing with nodes on non-local services. If you want
this behavior you're probably better off reflecting pubsub from remotes
into your local service through some means.
-bjc
