- From: Greg Stein <gstein@lyra.org>
- Date: Fri, 15 Dec 2000 15:12:45 -0800
- To: ietf-dav-versioning@w3.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 UTC