Re: DeltaV Lack of global properties

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?

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.

Cheers,
Geoff

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

   > Mutable properties are application defined properties on a
   > version resource
   > or version controlled resource with the following characteristics:
   >
   >    1. they can be changes at any time by a WebDAV client; and
   >
   >    2. they are cleared on a target version resource when that
   > resource is checked out.

   Can you explain this?  By "target version resource", do you mean when a
   new version is created with checkout, that mutable properties are
   cleared?  That does make sense.

   > This is certainly better than nothing, but three problems remain:
   >
   >   1. how can one trace who changed this property last;

   We don't trace who makes changes to regular properties in WebDAV.  I
   would call this out of scope.  A server can always do event logging
   according to its own design, without interfering with WebDAV.

   >   2. how can access to such a property be controlled; and

   I can tell you, this group will definitely not address property access.
   The ACL discussion may address property access control at some point.

   >   3. how can standard mutable properties be defined later?

   Lots of ways...
    - PROPPATCH could be extended to have an extra XML element or attribute
   to declare a new property mutable (PROPFIND may be extended to have the
   same)
    - A new method like CREATE-MUTABLE could create new mutable properties,
   which thereafter are set/read with PROPPATCH/PROPFIND.  In order to find
   out which properties are mutable, one could define a REPORT
   "mutable-properties".  This has the advantage of not requirng changes to
   PROPPATCH/PROPFIND.
    - Two new methods mirroring PROPPATCH/PROPFIND:  PATCH-MUTABLE and
   FIND-MUTABLE.  Presumably they'd duplicate the syntax, but only work
   with mutable properties on versions.  (kind of icky, if you ask me, but
   it's an idea).

   lisa

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

   > Just to be pedantic for a minute, if the client was totally
   > versioning unaware then they would be unaware that versions of
   > the resource exist, or the need for "global" properties.  A
   > versioning unaware client would set a dead property on an
   > autoversioned version-controlled resource, and that would be
   > carried forward through subsequent versions of the resource.

   But they would be aware of the need for a property like
   "Editor-in-Chief", they may need to get or set the value of this
   property.

   > Ok, so if a client was, say, versioning aware (i.e., knows
   > versions exist) but versioning challenged<g> (i.e., cannot make
   > versioning calls) then they could query the DAV:version-history
   > property of the VCR (using PROPFIND) to get to the version
   > history resource and set properties there (using PROPPATCH).  It
   > would not require any versioning specific methods to implement
   > the "global" properties.

   But they would also potentially know about the property
   "Editor-in-Chief".  And the versioning-aware client can look at
   past versions, where the "Editor-in-Chief" property really should
   not have a different value.

   So how are the two clients supposed to use the same property
   interoperably?

Received on Thursday, 8 February 2001 22:21:45 UTC