More detailed responses to responses... (was RE: Review of draft -08)

[this mail has well-indented sections from an earlier mail from me, sections
by <tim>, less-indented paragraphs are by geoff, and ends with my text
again...]

>    Section 5.2.6, DAV:version-name
>    Refers to Version URL. Where is this defined?
>
>    <tim> It isn't :-(
>
> In the 9.1 draft, all remaining uses of the phrase "version URL"
> have been replaced by "URL that identifies a version".
>

How do clients discover the "URL that identifies a version"?  I would think
it would be useful, though perhaps not required, to have this be
discoverable in a standard way.

>    Section 5.3, Version Selector Properties
>    How does a client definitively figure out if a URL points to a "Version
>    Selector", a version history, or a regular resource?
>
> Wouldn't it find out what it needs to know by asking the resource
> what methods, live properties, and reports it supports?

I'm not so sure... Since there's already so much variation in server
implementation possibilities (auto-versioning, automatic creation of
versioned resources, what URLs of versions look like, etc.)  I'd rather not
leave that up to the guesswork of the client.  I could imagine a resource
that "used to be" versioned appearing very much like a resource that is
currently versioned.  A definitive property that declares whether a resource
is a version selector, a version, or a version history would clearly fix
this.

>    Section 6.1, Overwrite
>    Does this section imply that doing a PUT, POST, COPY or MOVE with a
>    destination URL that is versioned with "Overwrite: T" header
> should delete
>    all the version history and replace the versioned resource
> with either a
>    non-versioned resource -- or a versioned resource whose
> history has been
>    deleted??  Please, please, say no -- versioning-unaware clients will
>    constantly be stomping on version-history if we define it this way.
>
> I assume that by "versioned resource", you mean "version selector"?
> The deletion of a version selector (resulting from Overwrite:T) has
> no affect on the version that is the target of that version selector,
> nor on the version history of that version.  They are three distinct
> and disjoint resources (in fact, in core versioning, you have no way
> of naming a version history resource, much less delete it).

OK, I'm confused.  I'm concerned about servers that support auto-versioning
here, so for those servers...

If I do a PUT to a version selector, isn't that interpreted as a write to
the resource whose versions are represented by the version selector?
Doesn't the version selector "pass through" most requests somehow?  Doesn't
the use of VERSION-CONTROL turn the target -- say "foo.doc" -- from a
regular resource into a version selector which points a version with the
contents that used to be in "foo.doc"?  I thought a PUT to "foo.doc", when
"foo.doc" is actually not a single-versioned resource but a version selector
which points to one of a selection of versions, would result in a creation
of a new version.  If that is true, then how is PUT with Overwrite:T
possibly going to overwrite the version selector?

>    Please clarify if "overwrite:F" should result in no write at all if a
>    versioned resource exists at the destination.
>
> Again, I assume you mean "version selector".  (Note to design team:
> think of the confusion that would have resulted if we had used
> the term "versioned resource" to mean "version history" :-).
>
> Overwrite:F has its usual semantics, namely abort the operation if
> a resource exists at the destination.

OK, I like that -- it doesn't violate the principle of least-surprise.
Please at least recommend that in the draft.


>    What if the source resource is not versioned, and the target is?
>    Surely what the user intends is to make the contents of the source
>    become the newest version at the target, not to delete the whole
>    version history!  Imagine I'm working in my personal directory on
>    some code/document, and when I've got it in a good/tested state, I
>    decide to put it into the shared code/document area, where files
>    are under version control.  Surely COPY is the natural way to do
>    this.
>
>    <tim> The natural way would, I suggest, be to checkout the destination
>    resources, update them with your personal directory contents,
> and checkin
>    the updates.
>
> I agree. In particular, if you have done any resource moving/renaming
> in your personal directory, you'd better do those moves/renames in the
> versioned area before doing your updates.

Fine, but neither of these answers answered my question.  What if in a COPY
the source resource is not versioned, and the target is a version selector?
I'd propose that the behaviour be to use the source content to create a new
version with that content at the destination.


>    Section 10.1 - VERSION-CONTROL
>    I would prefer not to have a separate method for this.  Would we need a
>    separate method for making something auto-versioned as well?
> I understand
>    the desire to convert an existing resource to a versioned resource; it
>    should be done with PROPPATCH since we've already got that method.
>
> VERSION-CONTROL does a lot more than just update a property on the
> resource identified by the request-URL.  It also creates a version history
> resource, and creates an initial revision in that version history.  I
> believe it would be misleading to make that all be the side effect of
> a PROPPATCH.

Why is this misleading?  Why is this any worse than auto-creation of
versioned resources, as proposed in the draft?


>    I am
>    specifically thinking of clients here, and how they can make
> fewer requests
>    (particularly when creating a new, versioned resource) and
> client coders
>    would write less special-purpose code (less bugs!).  As a server
>    implementor, this new method isn't as big a deal since I know
> I'd have to
>    treat the property specially instead.
>
> When used to create a version selector for an existing version history,
> the VERSION-CONTROL method takes two arguments: the location of the
> new version selector, and the version that should be its initial target.
> There's no way to marshal both arguments in a PROPPATCH.
>
> In any case, I don't see how you save any code by having PROPPATCH
> dispatch to your version control routine instead of having the
> VERSION-CONTROL method dispatch to the exact same routine.

Like I said, it's not the server that saves code in this particular
instance, but the client.  Clients that do versioning intelligently may be
possible with existing client APIs if we do this carefully -- with
PROPPATCH.

On the server side, it isn't code that is conserved, but testing and
specification effort may be.  It's easier to adapt a test suite that already
has PROPPATCH; it's easier to specify how PROPPATCH of a new prop should
work than to specify a whole new METHOD (with attendant headers, how does
each header interact with method, errors, etc).


>    ... If a resource is already
>    checked out -- can a "core-compliant" server refuse the
> CHECKOUT request?
>
> The server can refuse any command (heck, it's the server after all :-).
>
> To declare this behavior, set the (optional) DAV:checkout-fork property
> to DAV:forbidden (see section 14.1.3).  Then you would return a 409 status
> with <DAV:checkout-of-checked-out-version-is-forbidden/> in the response
> body of the CHECKOUT request.

Excellent.  Please put this in the draft.
We also need <DAV:multiple-checkouts-forbidden/> for servers which not only
do not allow checkout of a version that has already been checked out, but
also do not allow checkout on any version of a resource for which any
version has already been checked out.

>    Can you do a CHECKIN if you haven't done a CHECKOUT?
>
> Depends what you mean by "you".  You can do a CHECKIN on any resource
> that is checked out (i.e. a checked-out version selector or a working
> resource), assuming that a write lock does not prevent you from doing so.

So clients are recommended to LOCK, CHECKOUT, PUT, CHECKIN, UNLOCK if they
want to prevent other checkins in the meantime?  Fair enough.


>    Section 10.5, SET-TARGET
>    I'm proposing, in a separate mail, that this be replaced with
> PROPPATCH of
>    the DAV:target property.
>
> This would be a PROPPATCH with a very major side effect.  In particular,
> not only would it update the DAV:target property, but it would update
> the content and all the dead properties of the version selector as well.
> That's way too many side effects for my taste.

Why is it fine for a new method to have a bunch of side effects, but not for
PROPPATCH of a new property?

It's simple to design the property such that ignorant clients are extremely
unlikely to set the property ignorantly and surprise themselves.  Just make
the only valid values of the "DAV:target" property be values which the
client/user would be unlikely to come up with at random.  I think my
recommendation fit that bill, because it ensconced the URL in a <href> tag,
the name in a <name> tag, etc.

So if a server supports putting a URL to a version in "DAV:target", you
would set (in the body of the PROPPATCH):
  <D:target><D:href>http://foo.bar/my.doc,1</D:href></D:target>

If the server supports putting a label in "DAV:target", you would set
  <D:target><D:label>beta2</D:label></D:target>

Finally, if the server supports putting a version-name in a "DAV:target",
you would set
  <D:target><D:version-name>beta2</D:version-name></D:target>

Why is this any more dangerous than SET-TARGET?  It's no more likely to be
used accidentally!


A thought to throw out:  I would support replacing SET-TARGET and
VERSION-CONTROL (maybe LABEL, and maybe a couple others) with a new method
that treats "settings" (things with side effects) differently from
"properties".

So we could name this "SET" (or "SETTINGPATCH" or "CHANGE-SETTING" if you
want verbosity); It would be very similar to PROPPATCH in syntax.
 - This method would only be used to change one setting at a time, since
changing multiple settings at a time brings up concerns of the interactions
and order of application.
 - Atomicity wouldn't be a concern if it only changes one setting at a time.
 - We would only have to define syntax once -- whether depth is allowed, how
other headers might apply, what errors can be returned -- rather than define
syntax every time we want to do something similar to this in any DAV-related
protocol design effort
 - It would be a good "bundle" of activity -- like PROPPATCH -- to which a
single permission might reasonably be applied

Lisa

Received on Thursday, 5 October 2000 01:16:24 UTC