[Thunar-dev] Thunar Extension Framework

[Javier Aravena]

However it'd be nice to have support for fuse fs's through some kind of 
thunar-plugins package with the most possibly useful plugins (in addition to 
open terminal here, compress/uncompress and crypt/decrypt plugins)

2005/9/14, Anders Aagaard <aagaande at gmail.com>:
> 
> 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
> >
> >
> >
> 
> _______________________________________________
> Thunar-dev mailing list
> Thunar-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/thunar-dev
> 



-- 
Phrodo_00
--
http://ideasenteclado.blogspot.com
http://frodo-00.deviantart.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/thunar-dev/attachments/20050914/9cb6720c/attachment.html>