[Thunar-dev] Thunar Extension Framework

[Benedikt Meurer]

Tim Tassonis wrote:
>>>I think the argument of supporting "additional information like 
>>>metadata, mime/type etc" is fundamentally wrong, exactly because the 
>>>Linux/UNIX/Posix VFS layer does not support it. So you have to implement 
>>>the File/metadata mapping yourself anyway for 99% of all files you're 
>>>ever going to manage.
>>
>>You missed the point: The POSIX API is very limited. That's a limitation
>>we have to live with right now (the core of the API dates back to 1970,
>>so no wonder it's not very up2date).
>>
>>But what we're talking about is not how to apply this limitation to
>>newer systems; instead we're trying to find a solution for the future
>>(without this and other limitations).
> 
> 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. This is part of the point I'm talking about, and has nothing
to do with different opinions (it's a fact, independent of the way you
look at it). So even if the kernel's VFS layer doesn't support metadata,
you can still store metadata on these file systems (and for other local
file systems, you'll need a way to store it externally and that's
definitely easier and less error-prone in userspace than in kernel space).

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.

To continue with this example: MIME type detection is done on the
application layer today and the suggested way to detect the MIME type of
a document is to first check all magic rules with priority > 80, then
check all glob rules (literal, simple and pattern), then check the
remaining magic rules and if there's still no match, check if the first
256 chars are valid UTF8, else it's "application/octet-stream". Well,
this is the suggested way, but there's not a single implementation that
works this way (but that's a different story).

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.

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).

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.

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. The fact that something works
doesn't mean that it's a solution (nor does it mean that it's well done).

> Tim

Benedikt