Re: Comments on current version of the WEBDAV spec

Hi Andre,

>My proposal indeed violates the concept of opaque URL tokens; and indeed robs 
>server of the ability to implement their namespaces.  However, on purpose.  
>Let me try and ask the following question: how does the current WebDAV spec 
>address the following functionality: I have project X in 4 versions, with a 
>subproject Y with 6 versions, and a member of that subproject, called Z in 7 
>versions.  Now I would like to retrieve of version 3 of project X, version 5 
>of project Y, menber version 6: i.e.: X -> 3, Y -> 5, Z -> 6.  How do I 
>address this particular entity with the current spec, i.e., with the 
>versioning links and history resources?

The same way you would address any resource -- with a URL provided by
the server.  The URL is obtained by the client in the same way that
any URL is obtained: searching and/or following a link from a related
resource and/or cut-n-paste from some other source.  If there exists a
link from a given resource to one or more project/version history resource,
and there exists a link from that resource to the specific version
desired, or to some other project/version history resource that directly
or indirectly leads the specific version, then there exists a discovery
path for any version-specific URL.

In other words, you obtain the URL by the same process in which you decided
that what you wanted was X -> 3, Y -> 5, Z -> 6, with the only difference
being that you are following relationships in a web instead of numbers on
an implementation-dependent storage system.

>Can I address this entity with the current spec?

Yes, assuming you can discover its name.

>What is its name?

What the server decides to name it, which usually correlates to some
aspect of the backend implementation, but which does not correspond to
any knowledge inherent in the client.

>Can you show me how I carry out this naming? 

That is server implementation-dependent.  More importantly, it is not a
protocol issue if the name is always obtained from the server.

>If not: it certainly seems to be an important capability to have. I believe it
>is currently not possible, but so important and desirable, that I am willing 
>to violate the design principal.

I don't think you did a very good job of explaining why you need it.
I can't think of anything in NUCM that would need it, so there is probably
something that one of us has overlooked.

>If I don't, any server can implement its own 
>naming scheme, and I lose interoperability, because I can not built a client 
>that knows about every possible naming scheme. Conclusion: I would like to 
>standardize on the name space.

Attempting to standardize the name space breaks the separation of concerns
between client and server, making it difficult to wrap servers around
existing resources/gateways, and tying both server and client to features
based on the structure of the current namespace.  In my experience with
versioning systems like CVS, combining versioning and naming is a terrible
design decision, since it causes a resource history to break whenever the
name is changed.  The best solution to this problem is to separate the
versioning relationships from the storage of the versions, which just
happens to exactly mirror the implementation of a web server with support
for non-embedded links.  Given that we would like to develop those beasties
in any case (for things like annotation and collaborative linking),
the most general, and likely to be successful, approach to
web versioning is to treat the version history as a collection (DAG)
and provide general operations to manipulate that collection, which
are then translated by the server into implementation-dependent operations
on its own version space.

The issue of workspaces is an important one, since it impacts the
assumptions that a client can make while working locally (equivalent
to the problem of disconnected operation).  It should be possible for
the WEBDAV protocol to support an application that batches changes
into a single commit, even if "support" means just issue a sequence
of locks on the affected resources, issue the requests necessary to
make the modifications, and then release the locks.

However, I should say that I do not know if the current WEBDAV spec
provides support for these issues.  In fact, since the current spec
is not at all current (i.e., I know that many things have changed in
the minds of the authors since the last draft), I would be reticent to
describe anything within it as "WEBDAV". *hint* *hint*

Cheers,

.....Roy

Received on Saturday, 15 March 1997 11:21:23 UTC