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

The reason why "core" versioning servers, e.g. document management servers,
need a way to list existing versions (what I think is meant by "version
history") is because you need a way to tell the client what the URLs for
previous versions are.  The URLs are not calculable by clietns.

The format can be as dead simple as a list of URLs, though.

Is there any way that getting a list of revision URLs for a versioned
resource can work the same way as DAV clients currently browse directory
contents?  At least, the XML format can be similar:
<response>
  <href>~milele/public/advanced-status-reporting.htm?version=5</href>
  <propstat>
    <prop>
      <creator-displayname>Lisa</creator-displayname>
      <checkin-date>20001212T1332</checkin-date>
    </prop>
  </propstat>
</response>
<response>
  <href>~milele/public/advanced-status-reporting.htm?version=6</href>
  <propstat>
    <prop>
      <creator-displayname>Lisa</creator-displayname>
      <checkin-date>20001213T0942</checkin-date>
    </prop>
  </propstat>
</response>

Hmm, this really argues for using PROPFIND since the client can say what
props they want for the version.  Perhaps instead of using attributes in the
body of PROPFIND request (I never really understood where they would go)
there could just be an XML element to tell the server whether the client
wanted version detail or not:

PROPFIND thisresource

<?xml version="1.0" encoding="utf-8" ?>
   <propfind xmlns="DAV:">
     <versions>show-last-five</D:versions>
     <prop>
          <creator-displayname/>
          <checkin-date/>
     </prop>
   </propfind>

lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Greg Stein
> Sent: Friday, December 15, 2000 3:13 PM
> To: ietf-dav-versioning@w3.org
> Subject: Re: Minutes Delta-V breakout meeting 14-Dec-00
>
>
> 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 20:50:24 UTC