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

Re: Minutes Delta-V breakout meeting 14-Dec-00

From: Greg Stein <gstein@lyra.org>
Date: Fri, 15 Dec 2000 15:12:45 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20001215151245.E8945@lyra.org>
On Fri, Dec 15, 2000 at 04:03:50PM +0000, Tim_Ellison@uk.ibm.com wrote:
>...
> Discussed ways of working with client side workspaces.
> One model is that clients acquire locks across all resources that they want
> to update, sends updates, then releases all the locks.  This is inherently
> pessimistic, and isn't going to scale to updating large numbers of
> resources.
> Another model is to use GET and PROPFIND to copy resources over to the
> client machine.  Clearly clients must be stateful to maintain the resources
> and any subsequent changes to the resources made by the client.  (Clients
> may check with the server to ensure that the changes are still
> non-conflicting by considering the current server state.)  When time comes
> to make changes on the server the client checks out the versions, issues
> PUT and PROPPATCH to update the working resource on the server and CHECKIN
> the working resource.  Note that working resources are required since there
> is no single method for setting properties and content simultaneously.
> Some servers may have a batch capability to atomically check in numerous
> resources atomically.

A third model: the client does a CHECKOUT to get a working resource, then
does a bunch of PUT/PROPPATCH to that working resource. When the client is
done, it does a CHECKIN.

[ this contrasts to your model #2 where the client doesn't checkout until
  they are done with a bunch of local changes. ]

>...
> Should clarify in the spec. that 'Overwrite : T' means update in place
> (thereby ignoring the RFC2518 semantics that call for an initial DELETE of
> the destination).  Remove the 'Overwrite: update' option.

About bloody time.

>...
> Agenda item: should consider moving SET-TARGET out of core.

Please.

Without labels, the only thing that SET-TARGET could do is point at a
specific version, rather than "floating" with the latest. (hmm. how would
you reset the target to floating?)

[ and I don't want to implement SET-TARGET :-) ]

>...
> Suggested that there be no branching in core, no labels in core, but that
> there should be a version history available in core.

Um. Why? At the moment, I'm not seeing a need for these in Subversion. I'd
like to understand the need for these in the core.

[ I think the core should only be enough to support straight-line
  versioning, and enough to support down-level clients. ]

>...
> Should separate the 'label' option from the client managed workspace
> option.  I becomes its own option.

Yah, I saw this just a couple nights ago. I couldn't figure out why the two
concepts were mixed into the same section.

> How about a header to get the latest version in an activity?
> Suggest a REPORT against a version history to ask for the latest verswion
> in a given activity, the response includes a version URL (noted that you
> can issue depth requests if the target is a collection).

Couldn't you do this with a property report, fetching the DAV:activity-set
for each version resource identified by DAV:version-set of the version
history resource?

[ although this form would give you all the activities associated with a
  version history ]

Hmm. Something closer would be a property report fetching an activity's
version-set, then their checkin-date. The client could then sort them.

But yah... another report is possible, too :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Friday, 15 December 2000 18:09:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT