remove webdav as it lives on the real GSoCIdeas page now

[Imported from Trac: page GSoCIdeas/Notes, version 7]
zooko 2010-03-17 04:01:52 +00:00
parent 2f0fa7f760
commit ee1ce2cd29

@ -24,61 +24,6 @@ Students: you don't have to use one of the following Ideas. You can come up wi
* Help us author a paper proving the security of the crypto that will be used to implement new shorter caps (such as the [Elk Point protocol](NewCaps)/WhatCouldGoWrong or the "Semi-Private Key" construction from <http://allmydata.org/~zooko/lafs.pdf> ). [Tickets labelled 'newcaps'](http://allmydata.org/trac/tahoe-lafs/query?status=!closed&order=priority&keywords=~newcaps)
## WebDAV support
Difficulty: medium - hard
[Tickets labelled 'webdav'](http://allmydata.org/trac/tahoe-lafs/query?status=!closed&order=priority&keywords=~webdav)
WebDAV is a set of extensions to HTTP, specified in
[RFC 2518](http://tools.ietf.org/html/rfc2518.html) and
[a few other documents](http://www.ics.uci.edu/~ejw/authoring/),
that allow it to be used as a filesystem access protocol.
Supporting WebDAV in Tahoe would mean extending the
[webapi frontend]source:/src/frontends/webapi.txt to implement this
protocol.
The main attraction of implementing a WebDAV interface is that
several operating systems have bundled and somewhat integrated support
for it, including Mac OS X, Windows, and some Linux distributions.
In fact WebDAV may turn out to be an easier alternative to
[SMB/CIFS](http://en.wikipedia.org/wiki/Server_Message_Block)
for allowing filesystem access from Windows.
However, there is currently no working WebDAV implementation in Twisted
Python. There used to be one (the `web2.dav` package),
[but it bitrotted](http://twistedmatrix.com/trac/ticket/3081).
You'll have to decide whether to help fix that implementation, use a
non-Twisted implementation such as [WsgiDAV](http://code.google.com/p/wsgidav/)
that might be more difficult to integrate wth the existing Tahoe code,
or write your own. In any case, WebDAV is a complicated protocol and
you will need to decide what subset of it gives most "bang for the buck"
and is practical to support in the time available. For example, locking
is optional in the WebDAV spec; is it needed to interoperate with commonly
used WebDAV clients?
Unlike most filesystems which are constrained to be trees, the structure
of a Tahoe is in general a cyclic graph.
[draft-ietf-webdav-bind](http://tools.ietf.org/html/draft-ietf-webdav-bind) is
an Internet Draft that clarifies how WebDAV servers should handle cycles.
[davfs2](http://savannah.nongnu.org/projects/davfs2) is a FUSE-based
WebDAV filesystem client for Linux. To ensure that this runs correctly
over your implementation of WebDAV, you'll probably need to adapt the
tests for the existing Tahoe
["blackmatch"]source:contrib/fuse/impl_c/blackmatch.py FUSE interface
(this would not be redundant since the blackmatch implementation has
limitations, especially for write access, that davfs2 would not have).
The [WebDAV mini-redirector](http://en.wikipedia.org/wiki/WebDAV#Microsoft_Windows)
is the component of Windows providing its WebDAV filesystem support. It is
actually the less buggy of
[two implementations](http://www.zorched.net/2006/03/01/more-webdav-tips-tricks-and-bugs/), but it still has had
[bugs](http://greenbytes.de/tech/webdav/webdav-redirector-list.html) and
[security vulnerabilities](http://www.microsoft.com/technet/security/bulletin/MS08-007.mspx)
that you may need to take into account.
## Server Selection
*Which servers are connected to your client, and which of them have which shares of your files?*
=== Dynamically migrate shares to maintain file health. ===