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

Comments intermixed...
		-----Original Message-----
		From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
		Sent:	Saturday, February 06, 1999 9:51 PM
		To:	max@glyphica.com
		Cc:	w3c-dist-auth@w3.org
		Subject:	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.
		[CK] This requires then that a checkout token be passed as
part of the request.
		 We can do this, but how then is a CHECKOUT different
from a LOCK?
		 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.
		[CK] Agreed. Clients should hide the protocol from the user
model.
		 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.
		[CK] How then does one quickly discover the defined
configurations?
		 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.
		[CK] The lock portion is option in -01. I'm curious as to
why you don't
		 think the lock mechanism will scale?
		 (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).
		[CK] Very confusing. How did you identify the checkout?
You don't have
		 a lock-token and you used the same URL? If you
return a reivision-id
		 then it is part of the revision graph by definition.
This doesn't make sense.
		[CK] In order for a lock to make sense, it must be atomic
with the checkout.
		 As well, there must be interaction between lock and
checkout. That is,
		 Non-versioning-aware clients that use LOCK must be
able to block
		 Versioning-aware clients otherwise they will clash
and non-versioning
		 Clients will not be able to react.
		[CK] I also disagree with your premise about locks. I find
that people frequently
		 want exclusive locks when they checkout a resource
even if they have
		 merge facilities. It is a process issue.
		 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).
		[CK] I think the Workspace-Id concept is confusing and adds
an extra layer
		 of burden on clients. Maybe I just don't get it.
		 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.
		[CK] I can see why you would want to have a configuration be
based on
		 another, but I don't understand containment. If a
configuration is
		 a revision selection or a "thread" selection, then
containment makes
		 no sense?
		 I'm thinking of software development solutions: a
configuration might
		 represent a project, with subconfigurations containing
subprojects.
		Yes.
		[CK] So the disconnect is becoming more clear here. In -01,
a configuration
		 is viewed a the selection of a revision or a
revision thread. In this
		 context, a configuration would not be a project, but
the project at a
		 point in time.
		 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 Tuesday, 9 February 1999 01:52:34 UTC

AltStyle によって変換されたページ (->オリジナル) /