[Portland] PortlandVFSProposal

[nf2]

Diego Calleja wrote:

>El Sat, 07 Jan 2006 17:06:58 +0100,
>nf2 <nf2 at scheinwelt.at> escribió:
>
>
>  
>
>>http://mail.gnome.org/archives/gnome-vfs-list/2004-December/msg00061.html
>>    
>>
>
>
>Indeed, current Unix systems don't have a way to say "wrong password". Now
>the question is: if the userspace filesystem implementation is supposed
>to be (unlike it happens in common-vfs and dvfs) "transparent" should they
>_care_ at all? I still think that the whole point of userspace filesystems
>should be being transparent. That includes apps not being aware _at_all_ of
>what is going on.
>  
>
Well - You could register a GUI layer on top of vfs-libraries (which 
gets linked in by the applications) - like in Gnome. Or the backends 
could talk to a centralized daemon (via sockets), which would provide 
the auth-information and pop up the auth-dialogs. I guess FUSE could 
also work that way.

>(And notice that I don't think there's a reason why we can't add return
>codes to things like open() - SUS certainly defines error codes like
>ECONNABORTED altough they don't define it for open() but for network
>operations, but that's another issue)
>
>...and this doesn't benefits common-vfs task, since it means that apps
>not suited to network protocols will have to be redesigned to be aware
>of that, making the port of common-vfs even _harder_ than it already is
>(you'll need to patch every single unix command, if upstream doesn't
>accepts or doesn't likes common-vfs because they prefer FUSE you'll
>have to maintain it separately which will be a distro mainteinance hell)
>  
>
I believe with FUSE many applications need to be rewritten as well, 
because they don't expect the filesystem to be slow. With FUSE you have 
to move all your file-operations (even a "stat" call) out of the 
GUI-thread, because they might block for a very long time. I'd reckon 
not all applications do that. Thus the implications of migrating to FUSE 
or the Common-VFS are actually very similar.

The advantage of a common-vfs solution would be:

- You can use URIs
- You don't have the posix bottleneck for the interface (metadata, 
progress callbacks, directory columns,...)
- You can provide async features out-of-the box.
- You can ask the VFS if operations will be slow.

But i must admit the FUSE approach has charme too. Especially that it's 
very low-level...

Regards,
Norbert