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

Re: Simplifying CHECKOUT behavior for core versioning clients

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 2 Dec 2000 10:03:22 -0500 (EST)
Message-Id: <200012021503.KAA08309@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@lyra.org>

   On Fri, Dec 01, 2000 at 12:23:38AM -0500, Geoffrey M. Clemm wrote:

   > I believe we can address this issue by making branching an optional
   > feature (i.e. move it from core to optional).

   This is fine with me.

As Boris pointed out, I'm really proposing that we move "concurrent
development on a single resource" to core, not branching (just wanted
to verify that phrasing it that way, it's still fine with you that
we make it optional ).

   > Since "merging" is an
   > optional feature, and since branching is of limited value without
   > merging,

   Not so sure that I agree with this, but that disagreement doesn't bother me
   at all :-)

I don't agree with it either, so let's just forget I ever used
the term "branching" in this context (:-).

   That said: it is also reasonable to assume there are versioning
   systems that do not provide a way to keep changes private until
   "formal check-in." (a fileserver kind of operates this way)

Yes, that's a key point.  

In addition, since a client can keep its authoring state on the client
machine until it's ready to publish it, it's not clear how many
clients need additional support for private development from
versioning anyway (unless they also want parallel development).

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

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.
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).

   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.  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.

   If the server returns a working resource, the client must use it.

If the server redirects requests on a checked out version selector to
an associated working resource, the client must use it (the working
resource) as well ... it just doesn't have to know that it is.

   > 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?

Received on Saturday, 2 December 2000 10:04:04 UTC

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