Re: [long] Re: I-D ACTION:draft-ietf-webdav-versioning-01.txt

Max: A thoroughly excellent (and excellently thorough) review!

I'll respond to them in the context of "draft-clemm-webdav-versioning-00"
(mailed a bit ago to this mailing list, and available on the WebDAV
web site).  This will give a preview of some of the discussions that
will take place at the upcoming design meeting.

   From: Max Rible <max@glyphica.com>

   My biggest issue with the new draft of the versioning standard
   is the usage of gibberish temporary URIs where a user might have
   to cope with them or a system administrator might have to clean them
   up.

I agree.  I believe the argument to CHECKOUT, CHECKIN, and UNCHECKOUT
should always be a consistent human-comprehensible URL.

   Are there any actual cases where temporaries are actually 
   required, as opposed to a gibberish token that can be used in
   relation to a comprehensible URI?

I believe the client should not need to be aware of the location of
any such temporaries.

   There is a certain utility to having the magic files in a magic
   directory for ease of implementation-- you know you only have to
   treat a file in a special way if it's in a special location.  In
   my opinion, if you've already done the necessary work to make MKREF function,
   the additional amount needed to support checked-out files and
   configurations going anyplace should be small.

I agree.

   Is there a major flaw with the notion of CHECKOUT creating a locked, 
   mutable, non-autoversioned revision that the user holding the lock can 
   mutate arbitrarily until a CHECKIN is performed, at which point the 
   revision's name changes from a placeholder to a version number?  

I agree with the overall concept, i.e. CHECKOUT creates a mutable resource
at the specified URL, but I'd modify the following details:

I wouldn't want it to be a "revision" because this places excessive
constraints on the mutable resource.  In particular, a revision can
have only one descendent on a given branch, but you sometimes want to
allow a revision to have multiple CHECKOUT's to a given branch
(requiring a merge before any CHECKIN after the first).  But I don't
think that it being a "revision" was an essential part of your point.

Also, I would want the "lock" to be optional (I don't think the "lock"
mechanism scales well, and want it to be an optional part of the
versioning protocol).  Again, I believe this is not an essential part
of your point.

   (i.e.  
   CHECKOUT /foo/bar.html HTTP/1.1
   Host: www.foobar.com
   ...

I'd add an (optional) "Workspace:" header, which you can add to
indicate that you are checking out into a non-default workspace (a
Workspace is the resource that specifies how revision selection occurs
across the entire web-site, via a "revision-selection-rule" property).

   returns

   HTTP/1.1 201 Created
   Location: /foo/bar.html
   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>

I'd omit the Location header (it's always created at the place
specified by the CHECKOUT).

The Revision-Id is no longer necessary, since you either are
checking out into the default workspace, or you are checking
out into a specific workspace.  In any case, your workspace
determines which version you see, so no Revision-Id's need
to be passed in requests or reponses.

And I'd just use the LOCK command following the CHECKOUT if I want a
LOCK, rather than bundling LOCK with CHECKOUT (I don't believe the
frequency of CHECKOUT warrants worrying about an extra LOCK method call in
this case).

   and the combination of URI and Revision-Id can then be used for any
   number of PUT and PROPPATCH operations.

I agree (replacing "Revision-Id" with "optional Workspace-Id").

   When the user says

   CHECKIN /foo/bar.html HTTP/1.1
   Host: www.foobar.com
   Revision-Id: <opaquelocktocken:rejrei-43343-rereffre>
   Lock-Token: <opaquelocktocken:rejrei-43343-rereffre>
   ...

   the current version is frozen, given a non-temporary name (such as "1.2.1"),
   and the lock is released.

Yes (replacing Revision-Id with optional Workspace-Id, and making the
Lock-Token optional, in case you checked it out without a lock).

   If they UNCHECKOUT that URI/revision-id
   configuration, the revision quietly goes away.

Yes (i.e. the "working-resource" goes away).

   The same thing applies to configurations:  do they need to exist
   in special areas?

In draft-clemm-webdav-versioning, configurations have a much more
constrained purpose (and definition) than in draft-ietf-webdav-versioning.
In particular, they are effectively the mechanism for defining an
immutable-revision of a tree of resources (rooted at some collection).
They can then be specified in the revision-selection-rule of a workspace to
cause the appropriate revisions to appear in that workspace at the
appropriate URL's.

To illustrate the characteristics of the more constrained definition,
I'll answer Max's questions as if they were asked about the more
constrained definition.

*** NOTE ***
Max would not have asked these questions about the more constrained
definition ... he would have known the answers given below!  But his
questions and suggestions are very good for illustrating why the
more constrained definition might be preferable.
*** END NOTE ***

   Couldn't they be a part of a user's home
   directory on a server?  Direct references would make it possible
   to give the illusion of a configuration in your home directory, but
   now you have issues regarding cleaning up a user's files when
   moving their home directory from one machine to another or removing
   it entirely.

Like other CM metadata such as a "branch" or a "label", you would not
normally expect to find one in your home directory.

   Is a configuration so different from a collection that it should be
   treated as a separate sort of entity?  It looks like a collection
   that has a special sort of name (the configuration ID) and holds
   nothing but MKREF-created links to particular versions of files.

This is a read-only collection (it is immutable), and it is just a flat
list of revision references, with machine-generated names, e.g.
mem1, mem2, mem3.  So it's nothing a human would ever directly use to find
a revision of a particular resource (but is *is* something that a
workspace could use to efficiently find such a revision).

   (An aside:  should it be possible to use MKREF to link to a 
   particular version of a file, allowing the reference to provide the 
   Revision-Id or Configuration-Id header to a client who knows nothing 
   of them?)  Are there any fundamental differences that would make
   it difficult to consider a configuration as a collection with
   some added rules and functionality?

The creation of a configuration is an optimized server-specific operation.
Although it always results in a (read-only) collection, its creation
and storage will depend on factors that would not allow direct
creation or modification by a client.

   Should configurations be able to contain other configurations, or
   simply references to them?  I can easily see that a configuration's
   user might wish to partition it when it gets large and cluttered.

Yes.

   I'm thinking of software development solutions:  a configuration might
   represent a project, with subconfigurations containing subprojects.

Yes.

   You'd want automatic inheritance from the core project so any time
   someone else added a file to the configuration, you got a reference
   to it.

This is something you handle with workspace revision-selection-rules,
not with configurations (you can't add or remove files from configurations,
a configuration is immutable).

   A large project with a couple of dozen subprojects would
   otherwise be a pain to bring into a workspace, unless you had a
   development tool that dealt with all the repetetive actions for you.

Yes.

   (Direct references to other configurations could be used to 
   provide the illusion of nested configurations, but would require
   a lot of transactions make the parent configuration and then each
   child configuration inheriting from the originals.)

I'm not quite sure what this means, but I'd probably agree with it
if I did (:-).

   Might there occasionally be call for having non-reference members of
   a configuration?  I could easily see a checkin set that has no other
   reason for existence than its membership in a workspace.

Everything in a configuration is a reference to something else
(either a revision or another configuration).  To make something be
an immediate member would complicate the semantics with no obvious
benefit.

   Regarding the specification of the BRANCH command:

   Why was the decision made to use 

	  BRANCH VER:FHHR4959 HTTP/1.1
	  Host: www.foobar.com
	  Content-Type: text/html
	  Content-Length: xxxx

   instead of 

	  BRANCH /foo/bar.html HTTP/1.1
	   Revision-Id: VER:FHHR4959
	  Host: www.foobar.com
	  Content-Type: text/html
	  Content-Length: xxxx

I agree that it should be the latter (except that a Workspace header
rather than a Revision-Id should be passed in).  I also prefer the
method name "CHECKOUT-NEW", since this method is useful for
non-branch based servers as well.

   There has also been a massive growth in the number of available DAV
   properties.  PROPFIND allprop operations may lead to very large
   responses even with Depth: 1, which would slow down performance
   for users due to network speeds.  It might be worthwhile to add this
   facet to the open issue ALLPROP_AND_COMPUTED.

I believe strongly that defining useful properties should take
precedence over any desire that ALLPROP should run fast.  I personally
would vote to just nuke ALLPROP as a mistake, but as long as
clients know to never use it, I suppose it doesn't do that much
harm.

   Regarding SETDEFAULT:  why is it specified as sending an XML body?
   It it seems that 
	   SETDEFAULT uri HTTP/1.1
	   Revision-Id: DAV:none
   is equivalent to the request with a body and consistent with
   other usages in the specification.  Are there other data that
   may be used with SETDEFAULT at some point?

I believe SETDEFAULT is unnecessary, once you have the notion of
a default workspace, and therefore should be removed from the protocol.

Cheers,
Geoff

Received on Sunday, 7 February 1999 00:50:59 UTC