[Standards-JIG] JEP-0060 Feedback and questions.
stpeter at jabber.org
Fri Jun 2 21:29:00 UTC 2006
Peter Saint-Andre wrote:
> Brian Raymond wrote:
>> On 5/25/06 10:13 AM, "Ralph Meijer" <jabber.org at ralphm.ik.nu> wrote:
>>> But since I'm reading this anyway: Peter, I haven't looked at this
>>> before but it seems to me that this is wrong. If you have node that is
>>> configured to be transient and notification only, there would be no
>>> <item/> element in the notifications. How would this work with
>>> collections now?
> Hmm, good point.
>>> The are two possible choices for the node attribute on the <items/>
>>> element in a notification from a collection.
>>> 1) The original node to which the item was published.
> That is, the leaf node that is part of the collection.
>>> 2) The node to which the receiver was subscribed.
> That is, the collection node to which the subscriber subscribed.
>>> Option #2 seems problematic, because you cannot use the item ids to
>>> retrieve the item later (you have no idea which node it came from).
> But with a transient, notification-only node as the leaf node, there are
> no item IDs and therefore no items to retrieve later, right? However, it
> still would be good to know which leaf node generated the publish event,
> and for transient+notification nodes there is no <item/>. Hmm.
>>> Option #1 has the problem that the receiver cannot immediately see which
>>> subscription yielded that notification. For the subscription ID
>>> use-case, example 83 shows how to use SHIM to send along the subids that
>>> yielded the notification. We could add a similar header for collection
> Unfortunately, this seems to cause potential confusion. Usually the
> 'node' attribute of the <items/> element you receive from a collection
> node is the NodeID of the collection node and the 'node' attribute of
> the <item/> child is the NodeID of the leaf node that generated the
> publication event. But if the leaf node is transient+notification, then
> the <items/> node is the NodeID of the leaf node, not the NodeID of the
> collection node. That seems like a recipe for trouble.
Ralph, any further thoughts on this?
>>> Collection nodes do not support item retrieval as they can never persist
>>> items themselves. The prose above example 66 makes mention of this, but
>>> maybe we should make this more explicit in section 9. In any case, the
>>> result should be as in example 66.
>> You are right, they don't support item retrieval however I was wondering how
>> I go about requesting all of the direct children of a collection node. I
>> used Section 6.4 to point out how an entity would request the children of a
>> node, which means they get all of the items. What I don't see is how I would
>> structure a similar request to get all children of a collection node, it
>> sounds like there is no direct equivalent. You point out below that one
>> needs to use service discovery (disco#items) to retrieve all of the children
>> of a collection node.
> Well, in a sense, collection nodes *do* have items -- the items for a
> collection node are the leaf nodes associated with it (the collection
> node sends out an item when a new leaf node is associated with it). So I
> guess that you could retrieve all the nodes associated with a collection
> node by sending a get-items request to the collection node. But that's
> not specified right now. I'm not 100% sure yet that this makes sense, I
> need to think about it some more.
I keep wondering about this. It seems odd to send an <item/> element
when a new node is added to a collection, why not send a <node/> element
(or something other than <item/>)? Like so:
Example 186. Notification of new node
to='francisco at denmark.lit'
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards