[Thunar-dev] Thunar Extension Framework

[Tim Tassonis]

>> I don't think I missed the point, I just differ in the opinion as to at 
>> what level the limitation has to be solved. As long as the linux (or any 
>> other UNIX) VFS layer does not provide metadata information, you will 
>> always have to work around it and put a layer on top of it. This very 
>> same layer can just as well operate on remote systems, because most of 
>> the time those remote systems have an even lousier, more old-fashioned 
>> API than Posix.
> 
> I'm sorry, but you're really missing my point. I'll try to give a better
> explanation:
> 
> Most modern Unix file systems (e.g. UFS, XFS) and some Linux specific
> file systems (e.g. ext2/3, tho with limitations) already support
> extended attributes, which in effect means that they are able to store
> metadata. ...

I knew that, I just didn't mention it, because I didn't think it was the 
point of the discussion.

> 
> Whats even more interesting about *the point* is not that the file
> system is able to store metadata, but that the file system is able to
> provide metadata (not necessarily stored explicitly by the user). A
> simple example is the mime type detection here: If the file system (I
> use the term "file system" here to refer to the "VFS module") *can*
> provide this data, you'll have less trouble on the application layer.

Absolutely true, I knew that too. But did you knowthat fuse supports 
Extended attribute by means of getxattr() and setxattr() in order to 
read/store metadata and the Solaris vfs has a similar mechanism?

> The above requires fast access to the content of the document (atleast
> to the first ~256 bytes), which is not necessarily a problem for most
> local file systems, but will definitely be a problem for a directory
> with around 200 files on a FTP server. You may work-around a few of
> these problems by "guessing" the file systems type, but that'll (a)
> require a lot of system-dependent code and (b) require you to change the
> code everytime somebody comes up with another VFS module. And that's
> really not what makes up a stable and clean solution.

Absolutely true. That's why it would be better left to the VFS/Fuse layer.

> On the other hand, with a smart desktop VFS system, the various backends
> would determine the MIME type in whatever way is best suited for this
> backend and pass it to the application (for example, KIO already does
> this). This way you don't have one single MIME detector with ~1000
> #ifdef's in the end, and you can take advantage of backends that already
> provide the required data (e.g. an SVN backend would already provide the
> MIME-type and there's no need for detecting it at all).

Same goes with an svn FUSE filesystem.

> 
> And there's a lot more than the MIME-type to say about a file, and most
> of this is highly backend-specific and far from what can be provided by
> any kernel-VFS-hack/work-around: For example, "Trash.DeletionDate" and
> "Trash.OriginalPath" for the trash: backend, "Audio.Artist",
> "Audio.TrackNo" and "Audio.Title" for the cd: backend, and so on.

Could all be done using extended attributes, as in NTFS.

> 
> Don't get me wrong, FUSE is a good temporary work-around and I recommend
> it to people that want to access smb shares easily now, but you must be
> aware of the fact that it's really only a temporary hack and by no means
> a solution for the next 20-30 years.

I do think it _can_ be a solution for that.
Using extended attributes, FUSE can always export additional information 
just as a desktop VFS can. And it has the benefit that the filesystem is 
also available in any other environment apart from the desktop without 
any special library, just by fopen() and stuff. That's why I hope it 
_is_ the future.
But as always, the developers of fuse filesystems or desktop filesystems 
will decide. If great desktop vfs modules appear and only poor fuse 
modules, the vfs modules will be the future, because people will use them.
In this sense, right now, FUSE seems to have a slight advantage over 
D-VFS ...

Bye and thanks for the attention
Tim