Versioning collections question

I have been reading through all the WebDAV and now DeltaV specs etc
and so am slowing coming up to speed. I have a funny feeling that
some of the recent discussions that went over my head may actually
be answers to the following questions. But I am happy to make a fool
of myself in public :-)

My understanding is DeltaV supports versioning of all resources,
including collections. So if a MOVE is performed to change
/foo/a to /foo/b where /foo is a versioned resource, it is
possible to check in the new collection resource bound to /foo
and have /foo/b present in it instead of /foo/a.

Or put another way, the URI bindings to members of a collection are
a part of the parent collection and so are versioned with the member
collection. The member itself (the resource identified by /foo/a)
does not need to be versioned at all since it is not changed.

The reason I ask is I am looking at how to relate the DMA concept
of 'containers' to WebDAV/DeltaV 'collections'. In DMA, there is
a 'relationship' object that is created to link a member of a container
(that is, a 'containee') to the parent container. The 'relationship'
objet is therefore like a binding in WebDAV. I think there is however
a difference in that in DMA the parent container does not hold the
bindings (relationships). The binding objects (changing over to
DeltaV terminology) are independent to both the container and member.
The binding object holds the name, a pointer to the parent collection,
and a pointer to the member resource.

The impact of this is that to rename /foo/a to /foo/b does not require
the collection /foo to be versioned. Instead, the binding can be
versioned instead. The parent collection remains unchanged. The resource
also remains unchanged. I believe this is not the DeltaV model. I
believe that it is required to version the collection because bindings
are a part of the parent collection.

A picture might help. In WebDAV/DeltaV I think bindings are stored in
the parent collection object as follows. This means to change a binding
means the collection must be versioned.

         +------------+
         | Collection |
         |    foo     |
         +-----|------+
               |
	       v
         +------------+
         | Collection |      Renaming 'a' to 'b' requires this collection
         |  a     x   |      resource to be versioned.
         +--/-----\---+
           /       \
	  v         v
  +------------+  +------------+
  |  Resource  |  |  Resource  |
  +------------+  +------------+

In DMA, bindings are stored as separate additional objects. Collections
are pretty boring really. They main exist to be pointed at. The pointers
are in the binding objects which point at the parent collection and the
member.

         +------------+
         | Collection |
         +------------+
	       ^
	       |
         +-----|------+
         |   Binding  |
         |    foo     |
         +-----|------+
               |
	       v
         +------------+
         | Collection |
         +------------+
	    ^       ^
            |       |
  +---------|--+  +-|----------+
  |  Binding   |  |  Binding   |    Renaming 'a' to 'b' requires the binding
  |     a      |  |     x      |    to be versioned, not the collection.
  +-----|------+  +-----|------+
        |               |
	v               v
  +------------+  +------------+
  |  Resource  |  |  Resource  |
  +------------+  +------------+

The nice thing about the DMA approach is that /foo/a can be moved to
/bar/baz/other/a with the versioning of only one binding object.
The DeltaV approach in my understanding would require the /foo
collection and the /bar/baz/other collection both having new versions
created.

The reason is that the binding is more linked to the resource it is
bound to than the collection containing the binding. If you do a
MOVE, its the binding that is being moved.

My question is have I understood things correctly above in terms of
DeltaV? Since bindings are not resources in DeltaV I could see no
way to associate things like version numbers to them.

Alan


ps: Another model we had played around with was to represent the entire
directory tree as effectively a single 'configuration resource'. We
could represent this as a single XML document. Then for every change
to the directory structure, we would create a complete new version of
the XML document. There were problems with this in terms of merging
different people's changes, but it saved creating lots of little
persistent objects all over the place.

Received on Tuesday, 26 June 2001 03:17:34 UTC