[Thunar-dev] Thunar Extension Framework

[Benedikt Meurer]

Jaap Karssenberg wrote:
>>Maybe not for version one, but I think that it would be really interesting to
>>allow extensions to define "virtual files" and "virtual directories", in
>>addition to adding menu items and such.
>>
>>Use cases that I can see would be allowing programs like "Beagle" to provide
>>virtual folders as a plubin, which would contain running [saved] queries, or to
>>allow navigation within a tarball, or maybe some sort of "directory unifier"
>>plugin, to allow displaying all document directories across the computer as
>>one directory, and many other interesting uses.
>>
>>Of course, this is just an idea that I think would be cool to have.
> 
> Uhm just why exactly do you want to provide these as thunar plugins?
> 
> IMHO virtual filesystem goodies should not be implemented in the file 
> manager but in the "real" filesystem. What good are virtual directories 
> if your non-vfs-enabled programs can't use them !?
> 
> Take a look at projects like fuse <fuse.sf.net> for implementing virtual 
> directories at the right level.

Well, as discussed in various places before, FUSE is pretty useless,
because it (a) works at the wrong level and (b) is limited to Linux 2.4
and 2.6.

Doing remote file system abstraction in the kernels VFS layer is exactly
the wrong abstraction level, as that limits you to the POSIX API, which
is certainly not what you want in 99% of all (desktop use) cases, esp.
not within a smart file manager. E.g. there's no way for backends to
pass additional information (like the suggested mime type, metadata,
capabilities, etc.) to the application; you are limited to the plain
POSIX API. And even worse, the POSIX API imposes requirements on the
backend that require awful hacks to make it work with some remote
filesystems.

> just my 2p
> Jaap

Just my 0,019€,

Benedikt