[Standards-JIG] JEP-0060 Feedback and questions.

[Peter Saint-Andre]

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
>>> nodes.
>>>
>>> Ideas?
> 
> 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

<message from='pubsub.shakespeare.lit'
          to='francisco at denmark.lit'
          id='newnode1'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
     <collection node='some-collection-node'>
       <node id='new-node-id'>
     </collection>
   </event>
</message>

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20060602/3f3c1221/smime.bin