W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: DeltaV Lack of global properties

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Fri, 9 Feb 2001 23:07:04 -0500 (EST)
Message-Id: <200102100407.XAA29554@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

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

   > Just for interests sake, what would be the locking behavior of these
   > "shared" (a term I'd slightly prefer over "global" or "mutable")
   > properties?  If you lock a version, does that prevent change to that
   > property on all versions?  Are shared properties unaffected by write
   > locks?

   It depends how it's defined.  I'd prefer for a "shared"/"global"
   property to exist on the VCR only, not on any of the versions.  That's
   the easiest way for it to stay in synch across all versions.  Then,
   clearly, a LOCK on the VCR would affect the property as well.  A LOCK on
   a version would not.

Sorry, my typo.  I meant "If you lock a version-controlled resource,
does that prevent change to that property on all other version-controlled
resources for that same version history (you have stated that you
want the property to appear on all version-controlled resources
for that version history).

Is the property on the version history itself?  If not, does it
disappear if you delete the last version-controlled resource
for that version history (i.e. it's not there if you create
a new version-controlled resource for that version history)?

   (What is the meaning of a LOCK on a version, anyway?  If versions aren't
   mutable???)

Versions have live properties which can be changed, and if the
property is defined as being affected by a lock, a lock on
that version would prevent changes to that live property.
But as you say above, we should be talking about version-controlled
resources, not versions.

   Important note:  a "global" property is NOT the same as a "mutable"
   property.  A mutable property may exist on versions, may have different
   values on different versions, and most importantly, may be changed on a
   version without causing a new version to be created.

Fair enough.  I shouldn't have confused the two.  Note that the
protocol allows the server to have both global/shared and mutable properties
by just making them be live properties.  But I agree that there
is currently no interoperable way for a client to define that
they want a property to be live, and no way to define the
semantics of their live properties (e.g. affected by a lock,
mutable, shared/global, etc.).  But I believe that protocol for
this should be done in a general WebDAV forum, since defining
characteristics of live properties (kept on copy, single valued,
whatever) is a general WebDAV issue, not a versioning-specific
issue.

   > Note that although I'm always interested in exploring worthwhile
   > extensions to the WebDAV protocol, I'll point out that the versioning
   > protocol has received some criticism for being too complex because of
   > too many options, so I'm very reluctant to add even more options
   > before the IESG has a chance to review the ones that have already been
   > designed and reviewed.

   I strongly feel that BOTH mutable and global properties are required
   functionality for many source code and document versioning scenarios.

So are ACL's and Searching, but that's happening in a general WebDAV context,
because it involves general functionality that shouldn't be
tailored just to versioning needs.

Cheers,
Geoff
Received on Friday, 9 February 2001 23:08:36 GMT

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