W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

RE: Version-controlled collection resources - I am still missing something

From: Clemm, Geoff <gclemm@rational.com>
Date: Thu, 5 Jul 2001 10:23:53 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1038E14E9@SUS-MA1IT01>
To: DeltaV <ietf-dav-versioning@w3.org>

   From: Tim Ellison [mailto:Tim_Ellison@uk.ibm.com]

   > And in the version-controlled collection case, if your
   > server is sensible, and has the root version of a collection
   > always be an empty collection, 

   Wait-up<g> I agree with Alan that this is a useful implementation trick
to
   avoid this cascading of root versions, but if the act of creating a new
   version-controlled collection is very rare, I would rather my versioning
   server _didn't_ create 'bogus' empty root versions.

Introducing an empty root version will have no significant
implementation cost, and logically, it is very reasonable to say that
every new collection starts out empty, so there is no conceptual
problem here with users encountering a root version that is empty.

But whether or not an empty root version is "bogus" or "sensible" (:-),
the VERSION-CONTROL request is not expensive, because a server can
easily leave an "uninitialized" value for any such binding, and only
retrieve the root version if the client actually requests a value
from an unitialized binding.

   From the client's perspective, is it any better to have no members of the
   version-controlled collection (and have to fill them in explicitly),   or
   have the root versions for each member (and likely have to go and update
   them explicitly)?  I accept that for the server it is easier to not
create
   members.

The server can use basically the same implementation in either case.
The only question is whether it returns some "uninitialized" status
when you encounter one of those internal members, or returns the root
version.  Note that since the client is extremely likely to follow the
VERSION-CONTROL request with the appropriate MERGE or UPDATE request,
a client won't be encountering these "uninitialized" bindings very
often anyway.

   The members of a version-controlled collection created from a collection
   version are:
   (1) the DAV:root-version of the member's history (as proposed)
   an implementation note should be added to state that severs may chose to
   make root-versions of versioned collections empty to avoid cascading
   version-controlled collections.

or could just implement them as "uninitialized", and only retrieve the
root version if the binding is used before it is explicitly
initialized.

   (2) undefined and have to be explictly created by another
   version-control/merge request.
   i.e. when the version-controlled collection is created a PROPFIND depth 1
   would answer the internal member names, but attempts to GET them would
   return 404 Not Found.

I considered this, but it introduced what appears to be an unnecessary
obscure case (you'd need a DAV:uninitialized-binding-set so that a
client could discover what was going on here).  Note: I'm not against
this, but just thought the current way was simpler.

   (3) the spec is silent and servers do what they choose.
   It seems that clients are very likely going to have to go and fix-up all
   the members anyway so who cares about the initial value.

Yes, although I think it is better to define the behavior, so I
prefer 1 or 2.

   (4) forget that I even mentioned "latest" :-(
   Geoff wrote:
   > "latest" is a very bad choice ... I believe that selecting
   > the DAV:root-version is significantly superior.
   I agree that leaping around across branches is less than optimal, I was
   stumbing towards Alan's notion of the "linear series"

Note that this effectively would bundle "MERGE from activity" into the
VERSION-CONTROL request.  One of the reasons I resist bundling any of
these into the VERSION-CONTROL is that any variant of the MERGE or
UPDATE request is reasonable following the VERSION-CONTROL request, so
we'd have to give VERSION-CONTROL all the semantics of MERGE and
UPDATE if we wanted to do this cleanly.  Since I believe that there
are several techniques a server can use to make the initial
VERSION-CONTROL request very inexpensive (described above) , I think
it is cleaner to keep them separate.

Cheers,
Geoff
Received on Thursday, 5 July 2001 10:24:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT