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

> Von: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
>
>    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>
>    > Von: Clemm, Geoff
>    > This I believe remains the key argument.  Is future
>    > interoperability improved, unaffected, or harmed through the
>    > addition of these new resourcetype values?  My argument is the
>    > "like a duck" argument (i.e. if it looks like a duck and acts
>    > like a duck, even if it is some refinement of a duck, if your
>    > client does not know about that "duck refinement", it is better
>    > for your client to treat it as a duck than to treat it as an
>    > "unknown resource").
>
>    I think it's not only future interoperability, but also
>    interoperability as such which can be improved by explicitly
>    stating the type of a resource.  Rumour has it that code can have
>    bugs.  Sticking to the analogies in this thread, if your
>    mother-in-law does not report a property properly, the alligator
>    might look like a duck and eat your client alive.
>
> So the reason for adding values to DAV:resourcetype is that it is more
> likely for a server to be able to return the correct DAV:resourcetype
> value than it is for it to return the correct DAV:supported-method-set
> or DAV:supported-live-property-set value?  I find that rather hard
> to understand (much less, believe :-).

Not _the_ reason, but one reason, yes. 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.
And even for those we try to invent something like allprop/include to
gain acceptable performance.

Since <supported-live-property-set> is rather expensive (and was moved
out of allprop for that reason, right?) 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.
However that will break immediatly when some other type of resource
carries a version-name.

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

> The reason I'm applying so much time/energy to this thread, is that it
> is really a general DAV question that shows up (and will continue to
> show up) in every DAV extension.  I'd like to develop some guiding
> principle for "what goes in DAV:resourcetype", so that we don't end up
> having these same (often metaphysical :-) arguments every time the
> topic comes up.

Your time and energy is really appreciated. Such a guiding principle
would make life easier for everyone. Be it draft writers or implementors.

> For some historical background, I orginally proposed
> DAV:supported-method-set and DAV:supported-live-property-set because
> DAV:resourcetype wasn't giving me the detail I needed to populate my
> GUI's.  Certainly, before I had these two properties, DAV:resourcetype
> was essential.  This may therefore be one of those times where a
> protocol feature that was required has become redundant through the
> addition of later features.
>
> Cheers,
> Geoff

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.

Regards, Stefan

Received on Wednesday, 6 June 2001 06:21:52 UTC