On Tue, Nov 24, 2009 at 10:46:23AM -0500, Brian Cully wrote: > 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.
I'm pretty sure it is actually impossible to do properly as it is without that new header (or similar). Also, it is not possible to detect if you are subscribed to the leaf node *and* some containing collection. > > 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. Please don't take any of our schemas as final truth. That said, I think you are wrong. The xs:choice should denote there can only be one. Note that the default maxOccurs is 1. In general, there can be only one child element of <pubsub/>, except for including node configuration or subscription options. This might be considered a historic accident, as it would have been better to put those inside the <create/> and <subscribe/> elements. If this is not what the schema says, then it should be changed to reflect what I just said. There can be at most one <items/> element inside <pubsub/> (and no other elements in the same namespace). > 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. Maybe RSM is indeed a better solution. I'm just curious how well it works for retrieving one item at a time (likely when items are Atom Entry documents). -- Groetjes, ralphm
