RE: Resource class

   From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

   Im Auftrag von Tim_Ellison@uk.ibm.com
   > However...  It feels strange (in a woolly, hand-waving way) to
   > characterise a resource based soley upon its observed/stated
   > behavior -- especially given the existance of a
   > <DAV:resourcetype> property that is being used intuatively in
   > some cases (e.g. an activity), and not in others (e.g. a
   > version-controlled configuration).

   So, using Java terminology, we are talking about classes and
   interfaces.  Different classes are reflected in the resourcetype
   and the implemented interfaces are currently deduced from the set
   of live properties.

   So, maybe the designers of Java had also Tim's strange, wooly feeling
   about just relying on class properties and required that a Java class
   has to declare that it implements a certain interface.

More likely they just wanted to be able to efficiently compile code.
Since we are not compiling our HTTP method invocations,
there is no need for us to deal with the complexity and
overhead of a compile-time type and interface system.

   Therefore
   a) compilers/runtime can easily see what an object supports

Note though that we don't write HTTP method compilers, and runtime can just
use DAV:supported-method-set and DAV:supported-live-property-set.

   b) compilers can warn/fail if a class does not fully implement an
interface

Again note that we don't write HTTP method compilers.

   c) class designers can say what they mean. They avoid implementing
      an interface by accident. (What Tim talks about in the next
paragraph).

We're using this information to decide on what icon to display
to the user.  In this context, if it acts like a duck and looks
like a duck, using the "duck icon" is probably a good choice (:-).

A java compiler and runtime system uses this information for
a lot more than deciding on what icon to display, and therefore
reaches different conclusions on this issue.

   I should probably read more and propose less, but I would like a DAV
   property

   <implements xmlns="DAV:" xmlns:DV="DAV:versioning"
xmlns:DX="DAV:feature-X">
     <DV:versionable-resource/>
     <DV:versioned-resource/>
     <DX:x-type/>
   </implements>

   which is part of a standard propfind/allprop response.

What would this give a WebDAV client that it does not get
from  DAV:supported-method-set and DAV:supported-live-property-set?

Cheers,
Geoff

Received on Saturday, 2 June 2001 08:57:53 UTC