[Thunar-dev] Thunar Extension Framework

[Anders Aagaard]

Tim Tassonis wrote:

>>>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 ...
>  
>
Fuse is great because applications dont have to be changed.
D-VFS is great because they have to, as a developer knowing my programs
most likely has a fallback on what to do when a network stream is
interrupted and such, and wont deal with it as ioerrors (and most likely
die immediatly) is a good thing.

I like fuse, and I've even worked with it, but if d-vfs is the future,
it's not a bad thing ;)

>Bye and thanks for the attention
>Tim
>
>
>_______________________________________________
>Thunar-dev mailing list
>Thunar-dev at xfce.org
>http://foo-projects.org/mailman/listinfo/thunar-dev
>
>  
>