magic file system implementation

magic file system implementation

[Nic James Ferrier]

I want to implement my own magic "filesystem" over stateless HTTP (I
have the backend and a FUSE client already).

I have a few questions:


1. if one of the magic filesystem functions is not relevant to me,
what should I have that function do? For example, my filesystem cannot
have subdirectorys, what should make-directory and
make-directory-internal do?

2. Does anyone have a skeleton implementation of magic files? eldav is
pretty good but still quite eldav specific. 

3. What's the best prefix to register? TRAMP seems to have taken over
magic filesystems by registering:

  "\\`/[^/:]+:" 

to it's handler. This makes TRAMP the fs for anything with a url
scheme.


Making a generic module for filesystem handling seems like the kind of
thing that could be quite easily done to make life easier.

-- 
Nic Ferrier
http://www.tapsellferrier.co.uk   for all your tapsell ferrier needs

Re: magic file system implementation

[Stefan Monnier]

> 3. What's the best prefix to register? TRAMP seems to have taken over
> magic filesystems by registering:

>   "\\`/[^/:]+:" 

> to it's handler. This makes TRAMP the fs for anything with a url
> scheme.

You may want to check url-handler-mode as well.


        Stefan

Re: magic file system implementation

[Kai Großjohann]

Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I want to implement my own magic "filesystem" over stateless HTTP (I
> have the backend and a FUSE client already).
>
> I have a few questions:

I have no answers, but noone else has, so I can at least voice
suggestions.

> 1. if one of the magic filesystem functions is not relevant to me,
> what should I have that function do? For example, my filesystem cannot
> have subdirectorys, what should make-directory and
> make-directory-internal do?

Intuitively speaking, it seems they should fail.  It is not quite
clear to me, however, *how* they should fail.  But if you would make
them fail just like a normal make-directory fails when the permissions
are lacking, then that would be a good first approximation.

Since Ange-FTP is the oldest, it is always worth a look for
inspiration.  If it's been working for a decade, it can't be too
wrong.

I wonder if it would make sense to standardize on some file-error text
if the failure is to signal a file-error.

> 2. Does anyone have a skeleton implementation of magic files? eldav is
> pretty good but still quite eldav specific. 

I don't...  There is not much of a skeleton to implementing magic
files, though, except for the code to recursively invoke the file
operation, which is included in the lisp manual.

> 3. What's the best prefix to register? TRAMP seems to have taken over
> magic filesystems by registering:
>
>   "\\`/[^/:]+:" 
>
> to it's handler. This makes TRAMP the fs for anything with a url
> scheme.

This is the unfortunate consequence of the traditional syntax for
remote file names in Emacs: /user@host:/some/file.  Tramp continues
that tradition (and evolves it).

Practically speaking, I guess that using URLs instead of Emacs' custom
syntax has theoretical appeal, but won't happen due to immediate
benefit in practice...

What can I say here?  Tramp is also a framework to hook in other
remote file handlers, see tramp-smb.el which uses smbclient.  So one
approach could be to hook into Tramp...

Can't say, tho, what you would gain from hooking into Tramp.  Filename
parsing, perhaps, but how much is that worth?

Another approach is to rely on ordering: If you come first in
file-name-handler-alist, you win.  It is because this approach exists
that I believe it is unlikely that the Emacs filename syntax will
change.


Kai

Re: magic file system implementation

[Kai Großjohann]

kai@emptydomain.de (Kai Großjohann) writes:

> Nic James Ferrier <nferrier@tapsellferrier.co.uk> writes:
>
>> I want to implement my own magic "filesystem" over stateless HTTP (I
>> have the backend and a FUSE client already).
>>
>> I have a few questions:
>
> I have no answers, but noone else has

... voiced any so far ...

> , so I can at least voice suggestions.

Sorry, I didn't want to imply incompetence.

Happy New Year.

Kai