RE: Core versioning issues and nits

> > 7) How do you distinguish between:
> >  - A versionable resource
> >  - A non-versionable resource
> >  - A version-controlled resource
> >
> > Let's say the client wishes to present a simple UI which
> > lists all the resources in a collection, and can tell
> > what each resource is, allowing operations like "show me
> > the version history" or "turn versioning on" to be
> > available only when appropriate.  How, exactly, is this
> > accomplished?  What property is retrieved?
>
> Good question.
> A versionable resource will answer with (at least) Allow:
> VERSION-CONTROL
> to an OPTIONS request, a non-versionable resource will not.  A
> version-controlled resource is the only resource with a
> DAV:checked-in or
> DAV:checked-out property.
>
> There was some debate a while ago about making the resource
> types explicit,
> with various methods sugested.  I have to say that
> determining type by the
> presence or absence of properties is sub-optimal since, among
> other things,
> it makes for careful consideration when defining new resources with
> overlapping property names.

I agree that determining type by the absence of properties is
sub-optimal; I'd say it's not very reliable.  I'd point out another
problem:  in order to create the kind of GUI I described, the client
would have to:
 - Issue a depth:1 PROPFIND request to find all the resources that have
a DAV:checked-in (or checked-out) property.  If they do, consider them
VCRs.
 - Issue an OPTIONS request to every non-VCR, to find out whether it can
be versioned or not.

This is an order(N) operation, just to show a decent directory listing.
Depth is not supported on OPTIONS requests, according to RFC2518: "The
Depth header is only supported if a method's definition explicitly
provides for such support."

This is a serious client issue.  Please address...

Lisa

Received on Friday, 2 February 2001 15:20:52 UTC