Next message: Geoffrey M. Clemm: "Re: Baselines vs. labels"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256862.006462A1.00@d54mta03.raleigh.ibm.com>
Date: Mon, 10 Jan 2000 13:16:47 -0500
Subject: Re: proposed versioning usage scenario for client-managed checkouts
Chris,
This is great. Thanks. Just a few questions sprinkled in <jra> tags
below...
Chris Kaler <ckaler@Exchange.Microsoft.com>@w3.org on 01/10/2000 04:02:56
AM
Sent by: ietf-dav-versioning-request@w3.org
To: ietf-dav-versioning@w3.org
cc:
Subject: proposed versioning usage scenario for client-managed checkouts
Jim asked me to write up a protocol usage scenario for the case where the
client
is managing the checkouts as "tokens" rather that using the full workspace
support
a server might have. This is the impetus behind the "lightweight"
workspace concept.
Below is a first draft...
Client Managed Checkouts
Sally is writing a client tool, SuperEdit, that interoperates with a DAV
version store.
In SuperEdit, an isolated copy of her project files is maintained on the
user's client
system. She uses the DAV version store for staging, object versioning, and
configuration management.
<jra>
Just something to think about: how would some other WebDAV application that
Spike might want to run share the same working resources as those managed
by SuperEdit? This is the interoperability problem that distributed
workspaces was intended to solve.
</jra>
Initially, the user (Spike) specifies a path to a DAV collection that
represents his
project. SuperEdit then issues the following DAV requests:
<jra>
What does this URL look like? Is it a user URL or a server assigned URL to
a particular revision? If its a user URL, how is a revision selected?
Again, this is what workspaces with revision selection rules are supposed
to do, even if the client application chooses to cache all modified files
locally.
</jra>
- PROPFIND to determine the contents of the folder and the
settings of
important properties on the folder and its items
- GET on each of the items in the folder which are written to the
client's
local disk
<jra>
Again, what versions of these resources are selected for PROPFIND and
CHECKOUT?
</jra>
From within SuperEdit, Spike selects a file an issues the CHECKOUT command.
SuperEdit then issues the following DAV requests:
- CHECKOUT on the selected file(s) without specifying a target
selector
header
In the response header, SuperEdit finds the workspace that was allocated
for the
checkout. SuperEdit then stores this ID in its meta-base.
Spike proceeds to edit the file and saves the changes to his local system.
Eventually
he selects the "checkpoint" command. SuperEdit then issues the following
DAV
requests:
- PUT on the selected file(s) specifying the IDs returned from the
CHECKOUT
method as the target selectors
The purpose of the checkpoint command is to create a staged, but not yet
checked in
version of the file. Spike may, or may not, create a checkpoint.
Later, Spike issues the CHECKIN command on a selected set of files.
SuperEdit
then issues the following DAV requests:
- PUT on the selected file(s) that have not been check pointed or
that have
been modified since being check pointed, specifying the IDs returned
from
the CHECKOUT method as the target selectors
- CHECKIN on the selected file(s) specifying the IDs returned from
the
CHECKOUT method as the target selectors