Re: Backpointers

At 7:31 PM -0400 10/6/98, Jim Amsden wrote:
I'm definitely behind on the "backpointer" discussion, but since there's a
general meta-issue involved, I'd like to address that.

>My major objection is simply that there are a potentially infinite number of
>(live) properties that servers may choose to support. These could be based on
>server implementation, or associated with a particular application's use of a
>set of resources. It is impossible to predict what all these properties might
>be and what semantics they might have. We have to draw a line in the sand
>somewhere on what are DAV properties, and what are application or server
>specific properties.

This is all true. However, there are often well-known problems for which
the overhead of a complete solution is too high for the benefit we
anticipate. Sometimes we may be able to halp interoperability by defining a
property that can be used by servers and clients that attempt such a
problem.

>This is what the properties mechanism in WebDAV-08 was
>intended to support. Resources can have any properties they want, and servers
>can choose to support any live properties they want using a well-defined
>extensibility mechanism.

Exactly. A property provide the needed communication channel, and any
needed state in one package.

>Because property values are XML elements, a property
>can also be included that provides the DTD for these elements, perhaps as the
>property of some other related resource. Establishing "standards" for such
>properties consists of agreeing on these (perhaps implied) DTDs. That is what
>XML was designed for, and WebDAV properties makes good use of this important
>feature.

But since XML can support arbitrary DTDs, such an agreement need not be
made in advance, even though the property is probably much more effective
and interoperable if it is.

>Second, I think DAV properties should be minimized (and they are), and limited
>to the properties that are required to support the protocol. If no WebDAV
>method requires a backpointer in order to describe its semantics, then
>backpointers shouldn't be DAV properties. Finding links to a resource does not
>require a backpointer. It can be done, albeit inefficiently, by doing a
>search.
>The DAV spec should not be in the business of specifying implementations, even
>optional implementations. It should only specify behavior, semantics, and
>protocol mechanisms.

Here's where we have a difference of opinion. The meta-question might not
be whether a property is requiredby the protocol, but whether the
additional property will make things _harder_ for clients that don't care
about it. A second question is whether the existence of the property is a
significant step towards solveing the problem. (This means that this
argument can be used to justify a time-dilation-factor property for WebDAV
servers receeding at a multiple of the speed of light -- that doesn't make
a signficant step to solving the problems).

So my litmus test would be:
1. Are there enough people who need the property to make it worth helping
them, even if we are not going to solve their problems?
2. Does the property, in itself, make a significant step to solving that
problem?
3. Can server and client authors completely ignore this property if they
don't care about it?

>Although it is possible to specify a protocol that supports this, it
>will be difficult to write and USE clients that use it. WebDAV should minimize
>the number of optional features otherwise client complexity will outweigh the
>benefit. A protocol that has many options does not result in improved
>interoperability because of the number of permutations of options clients must
>be prepared to work with/around.

I do agree with this, but I think there's a difference between options that
require client reconfiguration, and those that do not. If simpler clients
need do little or nothing to support the existence of a server feature,
then allowing it is much less pernicious. For example, DAV currently allows
arbirtrary URIs everywhere, allowing clients to specify operations like
cross-server copies that we all expect _most_ servers not to support for
quite some time; restricting the URIs to relative URI paths within the
server receiving the request would not change the options that a client
needs to support, however. It also enables a clear and obvious migration
path for the future. I don't know if the current backpointer proposals work
the same way, but I think that the real issue is client impact for _not_
supporting a proposal, not just "number of options".

>I continue to encourage a conservative approach, and when in doubt, leave it
>out. This will facilitate building WebDAV servers on a large number of
>repository managers, simplify client applications, promote ease of use, and
>limit barriers to entry for WebDAV. Client applications are likely to be
>authoring browsers for some time to come. These applications are complicated
>enough without having to do a lot of work to configure themselves for many
>different servers providing a large number of optional features. WebDAV should
>concentrate on specifying fundamental, core capabilities, get them in client
>hands sooner than later, and let the customer tell us what more they need.
>Getting these core features in developers hands is likely much more important
>that most of the proposed options.

I do agree with this, and if the total number of options is too large, then
trimming based on the numbers is justified -- but it may well make sense to
_allow_ low-impact options for problems that are significant enough, even
if they are not completely solved. We're making the bed that we will have
to lie in, but we may want to avoid hiring Procrustes to tuck us in when
we're done!

  -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 7 October 1998 09:00:31 UTC