Re: Version issues

Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 17:00:17 -0800 

From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 17:00:17 -0800
Message-ID: <003f01be7ca4$2c4bd2c0$d115c380@ics.uci.edu>
Subject: Re: Version issues



-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Thursday, February 25, 1999 9:14 PM
To: jamsden@us.ibm.com
Cc: ckaler@microsoft.com; jamsden@us.ibm.com; ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@gw.novell.com;
sridhar.iyengar@mv.unisys.com; ckaler@microsoft.com;
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: Re: Version issues



   Chris Kaler <ckaler@microsoft.com> on 02/18/99 04:08:35 PM

   ... To set a default revision, they (level 1 clients) set the
   label on that revision to be "Default".  I think this is viable, but has
a
   few problems:

   1) When I use a direct reference to create a "share" in the namespace,
      I may (will) want to have different default revisions for /a/foo and
      /b/foo.  Using PROPPATCH to do this could be complex for servers.  I
      think that a method allows the easiest way for server and doesn't
      make the client any better or worse.

This approach to "exposing" different revisions in the namespace is a
good example of the kind of convolutions you have to go through
without workspaces.  And the semantics aren't obvious either.  What if
you do a MOVE from one such share to another?  Does the "default" stay
with the URL, or does it move to the new location?  Let's say you have
more than one of these "shares".  You may well set up a directory that
contains a consistent set of such "shares".  Starts looking more like
a workspace, but not in any regular way that another user or client
could unravel.  And of course completely incompatible with a level 2
client that is using workspaces.

   2) Since a revision can have multiple labels associated with it, to make
      it the default I must PROPFIND to get the current labels, add the new
      label, and PROPPATCH to change it.  To me, a help method would be
      very useful here.

There are a large number of primitive operations that could be combined
to "avoid an extra round trip".  I'd suggest collecting these all in
a separate document of "optional optimizations".  A "setdefault"
method would be a prime candidate for this document.

Cheers,
Geoff