[Standards-JIG] JEP-0060 Feedback and questions.
stpeter at jabber.org
Tue May 30 18:01:27 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
Brian Raymond wrote:
> On 5/25/06 10:13 AM, "Ralph Meijer" <jabber.org at ralphm.ik.nu> wrote:
>> On Thu, May 25, 2006 at 12:45:18AM -0400, Brian Raymond wrote:
>>> 1. Section 9.2: If an entity is subscribed to a collection node with type
>>> "items" and the server can return payload with a subscription notification
>>> can the server deliver the payload? The JEP states that the item if MUST be
>>> identified in the response however it isn't clear weather or not the payload
>>> can be returned as well.
>> I cannot really parse your question here. Are you referring to example
>> 199 in section 9.6? (I'm referring to the 1.8pre17)
> Yes I was referring to how a server returns notifications regarding
> collection node subscriptions if the server supports return payloads with
So let's say we have:
1. A leaf node called LeafNode.
2. A collection node called CollNode.
3. LeafNode is associated with CollNode.
4. ItemNode is configured to include payloads in notifications.
5. CollNode simply passes items through since it's just a collection
node (yes, I think an implementation could allow a collection node
configuration to override the configurations of its child nodes, but I
would say that is not recommended -- in general I think it's best for a
collection node to simply take what it's given and route it along to its
6. Subscriber is subscribed to CollNode with type="items".
7. Publisher is the owner of (or a publisher to) LeafNode.
7. Now Publisher publishes an Item to LeafNode and that Item includes a
Expected behavior: notification received by Subscriber includes a payload.
There's a legitimate concern here about sending a large number of
notifications containing payloads. Dealing with that is currently left
up to the implementation (e.g., removing the payloads at the collection
node rather than passing them through).
>> 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.
> Option 1 looks like it will work, however I think we do need an example for
> collections clarifying how you set the node attribute and use SHIM headers.
I'll add an example.
>>> 2. Section 6.4: An entity may retrieve all items associated with a node by
>>> requesting the node with no qualifiers. The following might be in the spec
>>> but I might have overlooked it, however what is the behavior if that request
>>> is made against a collection node?
>> 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.
(And yes, a collection node can be associated with another collection
node, I'm just simplifying things here.)
>>> 3. I thought I previously verified that an entity can request the entire
>>> subtree, including all items (with payload) and nodes from a collection node
>>> however I can't locate any information on that now, is this possible?
>> A disco#items on a collection node yields the nodes it contains.
>> A disco#items on a leaf node yields the items it contains.
>> The latter excludes the payload. That may be retrieved using the regular
>> item retrieval protocol.
What Ralph said. :-)
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards