Username or EmailPassword
Maybe they should base gnome's VFS on Fuse, so that all the virtual new paths and units would be visible to any app, even console apps, with no need for trekking all over the filing system.
They should replace gnomeVFS and kio-slaves with a unified, DBUS based protocol for accessing stuff (many of the more useful things you can do with a VFS need more information than is available through basic file operations; for example streaming content vs. copying it; should the backend keep a resource mounted, for how long etc.), that uses a Fuse (or something similar) backend for virtual mounts, that are accessible by all programs.
Ideally, the backend would be split up in a provider that does the mounting and plugins that access the data source; those plugins could be written in any language (otherwise you'd be losing half your developers) and could more easily do some funky data mining (e.g. a plugin that runs an html parser and takes a webpage -let's say osnews.com- as source, puts the text of the page in a file but also provides every link as a subdirectory -in this case the directory osnews.com would have a text.html file and a bunch of subdirs, one of them called "GNOME 2.18 Released").
I agree with this, FUSE would seem to fix a lot of annoying problems with gnomevfs.
No, it wouldn't.
gnome-vfs is a framework that goes far beyond the capabilties of FUSE. FUSE doesn't use asynchron operations, for a start.
The use of FUSE in gnome-vfs, it's merits and drawbacks has been discussed over and over again in the gnome-vfs-list.