The issue is
How do we extend the remote file hooks/syntax in Emacs such that is
allows access mechanisms other than FTP.
Yes, this is the issue.
1. Http. Free tools exist. Even pure elisp implementations.
2. rsh like. Free tools exist, i.e. rsh.
Right. So the simple question is, is there a uniform syntax that Emacs
can support for accessing files that includes a method to access them?
And again, I would argue that the syntax should be a URL (Or maybe,
more technically, a URI - if URNs ever get anywhere emacs should
support them too). Before we got sidetracked, we were discussing the
good and bad points of URLs.
The good points
1. URLs are a very widespread standard.
2. URLs work well for specifying resources on the net.
3. It is easy to encode an access method, username, password, and
filename in a URL.
4. URLs are extensible; you can easily add new methods, new naming
1. Many URLs contain //, and that means something special to Emacs
2. URLs are long
3. Many URLs (ftp, http) might make it awkward to express relative
filenames in the way that EFS does.
My proposal is that in the low-level functions that emacs uses to work
with files, if the filename looks like a URI then the resolution of
that to data should be delegated to a loader function. As a special
case, the EFS syntax (/username＠host:filename) should also be
supported; it should delegate to a "default" load method, which by
default should be ftp, but could be user settable to be something else.
As for bad points of URLs.. for #1, emacs should be smarter about //.
If the string looks like a URL, don't do the special stripping that
emacs does. For #2, I think supporting the EFS syntax as a special
case would take care of it. For #3, I'm not so sure - it has to be
handled on a case by case basis for each protocol. ftp is easy,
rcp/scp/ssh is easy, I'm not so sure about http.
One last little bit - someone will need to define a URL syntax for
methods that don't currently have URLs. ssh, for instance. That should
be done in coordination with the people who develop those tools.
. . . . . . . . http://www.media.mit.edu/~nelson/