For example, the paper Yaron and I wrote on WebDAV was submitted (and
accepted) to ECSCW'99 <http://www.ics.uci.edu/~ejw/papers/dav-ecscw.pdf>,
and not the WWW conference series because:
- the review process for (E)CSCW is more rigorous than for the WWW
conferences, and hence (E)CSCW is more selective, and more respected
- the target audience for a Web collaboration paper is well represented by
the attendees at (E)CSCW, but is a fraction of the attendees at a WWW
conference
Similar reasoning explains why Web-related hypertext papers often go to the
Hypertext conference.
> > You know, we had a
> >collaboration workshop a while ago, maybe we should have another [of
> >the 1995 confab Karen MacArthur managed??] Why aren't people sending
> >me cool little shareware programs doing this kind of collaboration?
> >[How about Office 2000?]"
>
> As cool shareware programs go, ...
Well, there is DAV Explorer, akin to Henrik's Web Commander, available at:
http://www.ics.uci.edu/~webdav/
It's freely available, and open source, and allows you to use DAV locking to
*prevent* overwrite conflicts before they occur.
The WebDAV Resources site, <http://www.webdav.org/> also has a good-sized
list of commercial and open-source WebDAV projects.
> >Tim, we need to have a chat. An Internet Proposed Standard *does*
> >exist for this application, and it deserves better than handwaving
> >about "oh, but we can do the critical part with just 1.1 and Jigsaw."
> >And it does deserve better than ignoring it entirely in public.
>
>
> Wrong. Dav does not do lost update protection - Dan just checked. HTTP 1.1
> does.
DAV does lost update *prevention*, which it recommends using *in
conjunction* with HTTP/1.1 lost update *detection*. Henrik describes this
is his latest tech. note:
http://www.w3.org/1999/04/Editing/
The bottom line is the mechanisms for *detecting* lost updates in HTTP/1.1
are complementary with the mechanisms for *preventing* lost updates in
WebDAV.
The problem with HTTP/1.1 is you cannot *detect* a lost update until you go
to write all of your changes. Furthermore, HTTP/1.1 gives you no way to
know that other people are editing the same resource at the same time. As a
consequence, if you are using an HTTP/1.1 authoring tool you will run into
the case where you have just performed edits on a resource, are going to
write them to the server, and you discover that someone else has written to
this resource before you. You then have two choices: (a) merge your
changes, assuming the tool has merge support, and the media type is amenable
to merges (how do you merge an image?) (b) write your changes to another
resource.
DAV locks give you a reasonable guarantee that while you are editing a
resource, someone else will not overwrite the resource. They thus *prevent*
lost updates while you are editing. However, to safeguard against the
possibility that the owner of the lock may have accidentally overwritten a
resource (perhaps by using another tool) while it was locked, we also
recommend the use of HTTP/1.1 lost update detection. In the best case, DAV
locks prevent lost updates, and the difficulties of merging, while in the
worst case, they gracefully degrade to providing the same lost update
detection capabilities of HTTP/1.1.
However, this exchange does highlight the need to re-develop the
relationship between W3C and the DAV WG. It's a shame there isn't more W3C
involvement in the Delta-V versioning and configuration management working
group, and there are still some issues concerning DAV properties and RDF
that need to be worked out. In the past it was somewhat contentious trying
to get W3C resources assigned to WebDAV, but I think it's time to revisit
this decision. I think you'll find the W3C membership very receptive to
this, since many of them (MS, IBM, Xerox, Novell, DataChannel, and many
others) are making substantial investments in DAV technology.
- Jim