On 24-Nov-2009, at 04:44, Ralph Meijer wrote:
> First of all, finding out which subscription(s) caused a notification is
> ambiguous, especially when the implementation supports subscription
> identifiers. I think we should include subscription information in a
> different way than with the current SubID and Collection SHIM headers. A
> possible solution is to use XMPP URIs to hold this information:
>
> <header
> name="Subscription">xmpp:pubsub.example.org?;node=mynode;subid=1234</header>
I like this. I've been sweating over the SHIM stuff for some time,
since our system uses multi-subscribe as well as collections, and the SHIMs are
too strict to code it up properly.
> Second, there is currently no way to retrieve items from a collection
> node. As I mentioned before, this would need modification to the result
> structure of the <items/> request. It cannot currently hold items for
> different nodes. I suggested to return the empty result, and then
> sending delayed notifications that match the items request as messages.
> This prevents very large stanzas and avoids the issue with multiple
> origin nodes. Probably we need some way to signal the difference from no
> results at all.
The XSD, as I read it, allows one to return multiple <items/> elements
as children of <pubsub/>. This is the approach I've taken for our system and it
works well. As much as possible I'd like to preserve or extend existing
XEP-0060 semantics for collection nodes, and returning an empty result with
asynchronous notifications thwarts the purpose of the get-items request (which
is to provide a synchronous response), IMHO. As I mentioned earlier, RSM, which
is already defined for standard leaf nodes, can be used for collection nodes to
reduce the size of stanzas.
-bjc
