Re: WeDAV Versioning Summary

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Mon, 19 Apr 1999 11:09:58 -0400 

Date: Mon, 19 Apr 1999 11:09:58 -0400
Message-Id: <9904191509.AA24929@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: jamsden@us.ibm.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <85256758.003E9569.00@d54mta03.raleigh.ibm.com>
Subject: Re: WeDAV Versioning Summary


The purpose of the "workspace as checkout-token" was to allow
interoperability between servers that require a heavy-weight
server-side workspace for a checkout and clients that want to do their
own workspace management.  It is prohibitively expensive for such a
server to allocate a new workspace for every checkout.

A solution to the problem is for such a server to allocate a small
"pool" of workspaces used for checkouts with no specified workspace.
When the server gets such a checkout request, it picks the first
workspace in the pool that doesn't have that resource checked out (a
cheap operation), and uses that workspace for the checkout.

To make this solution feasible, it is sufficient for the model to say
"each CHECKOUT produces a new working-resource", and *not* say
"each CHECKOUT produces a new workspace".

I'd go even further, and provide an "implementation note" that 
describes the above solution as a reasonable way for a "heavyweight 
workspace" server to implement the protocol.

Cheers,
Geoff

   From: jamsden@us.ibm.com

      <gmc> The server is allowed to use an existing workspace instead
      of creating a new workspace, so this should probably be "the server
      allocates a workspace for the checkout, possibly reusing an existing
      one, and returns this workspace as a `checkout token' for use by the
      client to identify the working resource."

      <jra>
      I dont' think this is the case. Only users can reuse workspaces
      (tokens or
      not) because reusing a workspace implies being able to see working
      revisions checked out in that workspace. You wouldn't want a server
      automatically making someone else's checkouts visible to you.


   <gmc>
   I believe this *must* be the case to achieve interoperability between
   a "token-based" client and a "workspace-based" server.  A workspace on
   a workspace-based server is far too expensive for it to have to create
   a new one on every checkout.  Since a token-based client will only use
   that "workspace" to access the single URL that it checked-out, this
   shouldn't be a problem.  Also, the "lock" that a token-based client
   will commonly put on the working resource will ensure that the working
   resource is not modified by another client.  So the fact that other
   clients may have checkouts in that workspace would not be a problem.

   <jra>
   But this doesn't work. Two users could checkout the same revision in the
   same workspace without an activity and not even know it.

Remember that in these checkouts, the *server* decides which workspace
to use, so it would just not choose a workspace from its pool that already
has a checkout for that resource.

   I think it is the
   client's responsibility to reuse "checkout tokens" as workspaces.

We are trying to handle the case where the client is *not* taking on
this responsibility.

   This
   seems to be what Chris wanted, client supported version namespace
   management rather than server supported. Given the flexibility implies
   handling the responsibility to do something with it.

Yes, Chris wanted clients to not have to take on the responsibility of
workspace re-use.  So we just have to design the protocol to allow
interoperation between clients that do not want this responsibility,
and servers that only support heavyweight workspaces.

Cheers,
Geoff