WEBDAV strategy questions (from Irvine meeting)

I expect we'll see minutes from the UCI meeting soon, but I thought
I'd give my short version of the trip report:

The meeting schedule was built around reviewing the specs components
in pieces. What didn't really become clear until near the end of the
meeting for me was that the members of the design team had taken a
fairly significant turn in <URL:webdav-draft-06.html>.

Originally, we had several designs (e.g.,
<URL:draft-ota-http-version-00.txt>, <URL:ns_dav.html>,
<http://www.aolserver.com/server/docs/2.0/html/acc-ch.htm>) that had
extended HTTP but still used the basic HTTP framework for doing
authoring operations. The latest design, however, had a complete
distributed object system framework, including a new syntax for
representing and discovering interfaces, a new syntax for transmitting
method calls using those interfaces, and a new representation ("web
collections") for representing the results of method calls; the design
team then implemented a fairly straightforward set of object method
calls to do authoring and versioning; however, in cases where it was
difficult to merge the many kinds of versioning and authoring
semantics available from multiple kinds of back-ends, the choice was
made to just implement all of the possibilities and make it possible
for the client to discover which kind of back-end it was talking to.

We spent most of the meeting critiquing the individual pieces of the
design; it was especially contentious because the documents had been
put together in a hurry and had a large number of errors, items left
on the cutting room floor without notice, and open design issues.

However, we only started discussing in the last hour the actual
strategy issue of the interoperability implications of the shift in
framework:

Strategy question 1:
      
There are many different kinds of versioning systems in the
world. Each of them embed a set of policies or policy choices
("checkout locks", "there are no locks", "locks always expire") that
were implemented and chosen for good reasons. What is our strategy for
dealing with these differences:

Priority A: Minimize impact on clients: a simple client should be
    able to do authoring against all backends.
Priority B: Allow known (or at least important) server policies to
    be visible and let knowing clients exploit those features
    when they are possible.

While we'd like to do both of these, I think, which is most important?
The design team chose "B is more important than A". I would prefer "A
is more important than B", but I imagine that this is not an item that
the working group as a whole would be in consensus. Of course, it
would be nice if we could discover a design where both priorities were
satisfied, but it's hard.

Strategy question 2:

Is WEBDAV _in_ HTTP or _on_ HTTP. Is it really just a few extensions
to the basic HTTP system, or is it really an independent protocol
which is most usefully transported in HTTP since the same machine that
supports document access (the HTTP server) is often the machine that
will support document authoring (the WEBDAV server).

I've not decided where I stand on strategy question 2. It will buy us
a lot of orthogonality to make WEBDAV somewhat independent of HTTP. If
we chose to go that route, though, we can't just implement a "WEBDAV
specific distributed object protocol" without some pushback from
others who need something like it but find our choice to be inadequate
in one way or another.

Anyway, that's my characterization of where we are and why the meeting
was a bit contentious.

Received on Friday, 31 January 1997 12:07:58 UTC