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

RE: Removing the DAV:activity and DAV:version-history and DAV:bas eline resource type values

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 6 Jun 2001 11:06:55 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1033E59E7@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

   My experience from implementing basic deltaV features in server and
   client code is that the code often (not always) deals with types of
   resources. "Is this a versioned, plain or version-controlled
   resource?" is a typical question.

   Both server and client code has the same concepts, but they are not
   directly communicated over the wire - only indirectly by properities.

So how is getting the information from DAV:resourcetype "directly
over the wire" while getting the information from DAV:supported-method-set
and DAV:supported-live-property-set "indirect"?  They are just two
properties, each containing a set of values, that the client is going
to look for particular values that are of interest.

And as Tim pointed out, the values we are going to end up putting
in DAV:resourcetype are going to start looking amazingly similar
to the set of values that currently exist in DAV:supported-method-set
and DAV:supported-live-property-set.

   And even for those we try to invent something like allprop/include to
   gain acceptable performance.

There are no performance issues that I am aware of that would
distinguish the performance of accessing DAV:resourcetype from
DAV:supported-xxx.  They are just fixed strings that are associated
with a resource when it is created.

   Since <supported-live-property-set> is rather expensive (and was moved
   out of allprop for that reason, right?)

No, it is not the value of DAV:supported-live-property-set that was
expensive (it is very cheap), but the values of the live properties
themselves which can be expensive.  

   I ask the server for specific
   properties (checked-in, checked-out and version-name) in order to
   deduce that a resource is plain, versioned or version-controlled.

No, you check to see if those values appear in the
DAV:supported-live-property set of the resource (which means the
server doesn't compute any of these property values, it just tells you
that they are supported).

   However that will break immediatly when some other type of resource
   carries a version-name.

What do you mean by "break"?  The DAV:version-name property has 
certain well defined semantics.  If your application wants to do
something that depends on those semantics, it can do those things
on *any* resource that supports that property.  The dependency is
on whether or not the resource supports that property, not whether
or not the resource has a certain "type".

The only things that an interoperable client can "do" on a resource is
perform methods on the resource and access properties.  If a resource
supports a particular method or live property, you are guaranteed
(if the resource is implemented properly) that you can do what that
method says, or what that live property provides, which means it
*won't* break.

   So, I am looking for an airbag and seat belt - I do not want to
   remove any horse power so that it would be safe to drive without any. ;)

But it's important to keep in mind that we are not actually talking
about driving a car, but rather interoperating with web servers (:-).

   I still think that both have their value and purpose. Excuse me
   bringing back Java analogies, but reflection in Java is a very
   powerful feature and you can do lots of useful, flexible things
   with it. However there are also interfaces and it's good that they
   are there for speed and type safety.

Although Java is a closer analogy than ducks, alligators, and 
mother-in-laws (:-), it is still just an analogy, and you can make
an analogy reach any conclusion you want.  For example, you can
make an analogy with Smalltalk.  The reason why Smalltalk is such a good
prototyping language, is that it *does not* require you
to declare types, but rather allows you to invoke a routine on
any object (resource) that supports the method you are invoking.
Like Smalltalk, we want our protocol to continue working even when
the caller (the client) is modified or the callee (the server)
is modified.  The benefits of explicit type definitions is that
it is easier to do separate and efficient compilation.  But we
*don't* compile our HTTP method calls ... we just invoke them,
which is where the Java (and any strongly typed language) analogy
breaks down, but the Smalltalk (and Lisp, and ML, and most other
good prototyping languages) analogy holds.

But there I go again, indulging in analogy games ... (:-).

Received on Wednesday, 6 June 2001 11:02:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC