On 11/24/09 11:16 AM, Brian Cully wrote: > 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.
Agreed. > 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. Agreed. I don't think we need or want versioning for node configuration, only the items published to the node. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
