webdav advice sought

webdav advice sought

[Thomas Lord]

I am working on a project that includes improving
"webdav support in Emacs".  I plan to submit patches
and/or new code.  I am writing to cross check my
thinking about how to do this before I get too
deeply into it.

I would appreciate helpful suggestions about
what information I'm missing, about which of my
alternative (tentative) plans makes the most sense,
and about what better plans I might have missed.

WebDAV is, of course, a protocol layered on top
of HTTP providing support for a remote file system.

I would like Emacs to be able to treat WebDAV servers
as a regular file system - to be able to "find-file"
a WebDAV file, to be able to save files, to have dired
work and so forth.  I would like advisory locking to work.
I would like to, at least by default, have auto-save files
go locally.   I am explicitly not, at this stage, concerned
with the WebDAV features and extensions related to versioning.

I understand that there is limited VC-mode support
for WebDAV though I don't know much about that yet.
That is not quite what I'm looking for (I think).  I
understand similarly about w3 mode webdav support.

I understand that there is some (somewhat bit-rotted) support
from a third party package called "eldav", which relies on 
an unmaintained program called "nd".   The current state
of ange-ftp-like support for WebDAV is a bit sad, as far
as I can tell.

First question: have I missed something about the current
state of things?

Second question:  what makes sense here?:

1. Try to rehabilitate eldav?
2. Try to adapt ange-ftp to use "cadaver", a command-line
   webdav client similar to typical ftp client programs?
3. Try to adapt tramp, again using cadaver?
4. Use ange and tramp as a guide but write a new set
   of file hooks, presumably using cadaver?
5. One of the above, but don't use cadaver, use ______?
6. Write C code for Emacs core (adding new library dependencies)?
7. Tom, you dummy, none of the above.  Instead ________?

I have my preferences from the above list but I
won't bias things yet by stating them.


Thanks and Regards,
-t

Re: webdav advice sought

[David Reitter]

On Jun 23, 2009, at 7:26 PM, Thomas Lord wrote:
>
> I would like Emacs to be able to treat WebDAV servers
> as a regular file system - to be able to "find-file"
> a WebDAV file, to be able to save files, to have dired
> work and so forth.

What advantages do you see in implementing this in Emacs rather than  
doing this at the operating system level where other file systems are  
implemented (or maybe using FUSE)?

http://savannah.nongnu.org/projects/davfs2
http://fuse.sourceforge.net/

Re: webdav advice sought

[Jason Rumney]

Thomas Lord wrote:
> Second question:  what makes sense here?:
>
> 1. Try to rehabilitate eldav?
> 2. Try to adapt ange-ftp to use "cadaver", a command-line
>    webdav client similar to typical ftp client programs?
> 3. Try to adapt tramp, again using cadaver?
> 4. Use ange and tramp as a guide but write a new set
>    of file hooks, presumably using cadaver?
>   
Of the above, I think 3 is the preferred approach - create a new tramp 
backend for webdav (probably the closest current implementation to 
follow is tramp-smb.el, as most other tramp protocols involve shell access).

> 5. One of the above, but don't use cadaver, use ______?
>   
url-dav.el, improving as necessary?  It would be good to have completely 
native Emacs access to webdav without relying on external programs that 
in most cases will not be installed on the user's system already.

Re: webdav advice sought

[Michael Albinus]

Thomas Lord <lord@emf.net> writes:

> 3. Try to adapt tramp, again using cadaver?
> 4. Use ange and tramp as a guide but write a new set
>    of file hooks, presumably using cadaver?
> 5. One of the above, but don't use cadaver, use ______?

Two days ago, I've committed tramp-gvfs.el to the trunk. It offers the
new methods dav and davs. If the limitation to rely on gvfs is OK for
you, it might be what you are looking for. Otherwise, I'll be happy to
support you in implementing option 3.

> I have my preferences from the above list but I
> won't bias things yet by stating them.
>
>
> Thanks and Regards,
> -t

Best regards, Michael.

Re: webdav advice sought

[Thomas Lord]

On Wed, 2009-06-24 at 06:49 +0200, Michael Albinus wrote:
> Thomas Lord <lord@emf.net> writes:
> 
> > 3. Try to adapt tramp, again using cadaver?
> > 4. Use ange and tramp as a guide but write a new set
> >    of file hooks, presumably using cadaver?
> > 5. One of the above, but don't use cadaver, use ______?
> 
> Two days ago, I've committed tramp-gvfs.el to the trunk. It offers the
> new methods dav and davs. If the limitation to rely on gvfs is OK for
> you, it might be what you are looking for.

"wild thing, I think I love you" [1]

I see it in my cvs tree.  I'll try it out
and will check out the gvfs protocol to see how
I feel about it.   I suspect that, indeed, this
is more than OK for my needs and that you just
saved me a lot of grief.

-t

[1] http://en.wikipedia.org/wiki/Wild_Thing_(Chip_Taylor_song)

Re: webdav advice sought

[Thomas Lord]

On Tue, 2009-06-23 at 21:09 -0400, David Reitter wrote:
> On Jun 23, 2009, at 7:26 PM, Thomas Lord wrote:
> >
> > I would like Emacs to be able to treat WebDAV servers
> > as a regular file system - to be able to "find-file"
> > a WebDAV file, to be able to save files, to have dired
> > work and so forth.
> 
> What advantages do you see in implementing this in Emacs rather than  
> doing this at the operating system level where other file systems are  
> implemented (or maybe using FUSE)?

1. Portability

2. Ultimately, being able to take advantage of a full
   DAV API rather than being limited to a POSIX API.

This isn't to say that an OS-level DAV gateway
isn't useful.

If I had "infinite resources and speed" I would 
cons up a version of Emacs (and many other programs)
with no (directly made) POSIX calls at all.  
Instead, use an HTTP-based API as the system call
mechanism, DAV as the basis of file system system
calls, routable URLs regarded as processes (some of
which create new processes in response to certain
forms of request), XML as the primary means of
marshalling and unmarshalling structured data in
messages. and so forth.   You could think of it 
as a bit like the HURD but generalized.


-t