Re: Core versioning issues and nits

   From: "Lisa Dusseault" <lisa@xythos.com>

   > > 7) How do you distinguish between:
   > >  - A versionable resource
   > >  - A non-versionable resource
   > >  - A version-controlled resource

   > 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.

One person's "resource type" is another persons "resource state".
Is "checked-out" a resource type or a resource state?  Is "locked"
a resource type or a resource state.  Is "under version control"
a resource type or a resource state. ...

So either you need to carefully consider your choice of property
names (which you should do anyway), or carefully consider your
choice of "resource type names".

   I agree that determining type by the absence of properties is
   sub-optimal; I'd say it's not very reliable.

How is it any less reliable than looking for a particular value
in a "resourcetype" property?

   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.

Now this is a good argument for turning the DAV:supported-method-set
back into a property!  Which is what James Hunt has just asked us
to do.  I asked him "why".  I think this is a pretty good answer.
So I'd propose that we switch them back, based on this point that
Lisa has made.

Any objections? (I assume that at least James will be in favor :-).

   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...

I assume turning the supported-xxx information back into a property
addresses this concern?

Cheers,
Geoff

Received on Sunday, 4 February 2001 20:06:05 UTC