- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Fri, 31 Jan 1997 08:07:23 PST
- To: w3c-dist-auth@www10.w3.org
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