On 19-Nov-2009, at 15:54, Andy Skelton wrote:
> This expands the version concept in two directions. First, should this
> versioning then also apply to Collection Nodes? The version ID e.g.
> could be "a hash of the collection" or "a hash of the versions
> contained in the collection", take your pick. Second, should
> versioning also apply to items, as the section title implies?
I have no idea what to do in the case of collection nodes, which is a
shame, because those are the kinds of nodes I'm going to be dealing with and
where `ver' would be most helpful. As a stab in the dark, I would think that a
collection updates its version whenever a node or item change happens with one
of its descendants (remember that there are two subscription types for
collection nodes: items and nodes). I think that would cover all cases, makes
an even better argument for opaque versions (assuming one likes collections,
anyway), and doesn't incur any significant overhead.
The worst case I see is a node change updating a version without
changing items, but in those cases, a get-items with an old `ver' attribute
will simply return the empty set.
On a similar note, does `ver' apply only to the items within the node,
and not the node configuration itself? It seems to, and this is certainly the
most useful application, but since we have the distinction it might be worth
thinking about. After all, I can get events when a node config changes, and I
may actually care about this. Then again, if node config is changing that much,
I'd bet dollars to doughnuts that you're doing something wrong.
-bjc
