W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Simplifying CHECKOUT behavior for core versioning clients

From: Greg Stein <gstein@lyra.org>
Date: Sat, 2 Dec 2000 08:57:37 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20001202085736.N12166@lyra.org>
On Sat, Dec 02, 2000 at 10:03:22AM -0500, Geoffrey M. Clemm wrote:
>    From: Greg Stein <gstein@lyra.org>
>    > Note that a
>    > server that is "working resource" based can easily implement this
>    > behavior by associating a working resource with the version selector
>    > while it is "checked out", and direct all operations on the version
>    > selector to this working resource.
>    This is dangerous behavior to tell clients to use. For a server that *wants*
>    private changes to be possible, and wants the client to use the working
>    resource, then clients using the above behavior will choke.
> It's fine for a server to want private changes to be possible, but that's
> different from it wanting the client to use the working resource

Agreed the difference exists.

> (if
> a client doesn't want to make its changes private, why would a server
> care whether it uses working resources or not?).

The server cares because the working resource is the "point of entry", if
you will, for modifying the resource.

> As for a client choking, that's what will happen with the current protocol
> if a client tries to use a working resource model against a workspace server.

Nope. When you do a CHECKOUT, the server will do one of two things:

1) it is a workspace, so it checks out in place. the client continues to
   work with that resource

2) it returns 201 (Created) with a Location: header pointing to the working

The point is: the response may or may not provide a Location: header to tell
the client what to do. The client should always respect that.

You said the client would choke if it expected the working resource model
against a workspace server. Not at all... it would not see a Location: come
back, so it wouldn't alter the URL to use for modifying the resource.

> So the modified model doesn't add any more client choking than is in the
> protocol already.  (That's not quite true, since with the current protocol,
> if you designed a client that worked with both the working resource and the
> workspace models, you could avoid choking, but I believe there will be
> very few such clients).

Simple examination of the Location: header. I would expect most clients to
be able to work with both.

>    If they do a CHECKOUT on a v-selector, then do a PUT to it (even if
>    the server gave them a w-resource), then the PUT will fail.
> I don't follow you here.  I've got a server whose implementation is
> based on working resources.  The server simulates a checked-out
> version selector by secretly associating a working resource with the
> version selector when it is checked out.

Ah! See... that isn't in the specification. You're asking for more behavior
on version selectors than exists today.

I disagree with this addition. Again: you're trying to swing everything
towards something like a checked-out version selector model.

The client should simply use the Location: header.

> The server redirects all
> request to that checked-out version selector to that working resource.
> When a client issues a PUT, the PUT gets redirected by the server to
> the working resource, and the PUT succeeds.  When the checked-out
> version selector is checked in, the server checks in the secret working
> resource and sets the target of the version selector to be the newly
> created version.

Disagree... strongly. That is quite different from today's spec, and I don't
see a basis for this except to allow clients to ignore the Location header
and continue working with the same request-URI.

>    > We would then define two alternative forms of optional parallel
>    > development, "client side workspaces" (with working resources) and
>    > "server side workspaces" (with workspaces).
>    I like the distinction of server types. However, I'm not sure that we can
>    make a simplification as you suggest (e.g. only use v-selectors).
> Did the above clarify how I believe a working resource based
> implementation would provide v-selector checkout?

Clear, yes, and I don't think that it works well.

Clients that ignore the Location header will break when you have an advanced
server which provides for parallel development. That server cannot allow
clients to continue working from the v-selector. The clients *must* work
from the working resource.

But the cool point is: you can still have the same dumb client talking to
this advanced server, as the client talking to the dumb no-parallel server.
The model the client sees is the same.


Greg Stein, http://www.lyra.org/
Received on Saturday, 2 December 2000 11:55:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC