system and desktop VFS merged

[John Davidorff Pell]

On 27 Mar 2005, at 11:59, Sean Middleditch wrote:
> On Sun, 2005-03-27 at 22:32 +0300, rosen georgiev wrote:
>>
>> if the vfs layer thing is not possible , what about the first 2 of  
>> the
>> Desktop VFS "standarts" - they are just rules and are very easy to  
>> implement,
>> and totaly transparent to the API, _and_ will make it really easy  
>> for everyone
>> who wants to use the likes of FUSE-DVFS. I'will paste them here again
>>
>> 1)     The API of the VFS must except filenames in absolute or URI
>>     form. both protocol://<path> and /vfs/protocol/<path> should
>>     be valid, where "/vfs" must be a standart for all APIs. It  
>> must be
>>     totaly transparent to the program
>
> I really see no purpose in using the VFS path stuff.  Classic UNIX  
> uses
> mounting.  If a user wants their legacy app to access a remote share,
> they should mount it just like they currently do with sshfs or  
> smbfs or
> whatever.  They can mount it anywhere they want - I usually mount  
> remote
> shares in ~/.mount/ for example.  If a user wants a dynamic mount  
> area,
> I'd suggest having the individual users mount such a dynamic  
> filesystem
> in their home folder as well.

I must agree with Rosen. I think that it would be necessary to use  
this standard path structure to allow easier integration with non- 
DVFS aware apps. I think that the daemon should mount filesystems  
that are easily moutable/that must be mounted somewhere in /vfs, this  
way allowing "Classic UNIX" apps, as you put it, easy access to the  
share. Deliberately trying to avoid this I think is a poor decision  
and only serves to demonstrate prejudice against non-Desktop apps.

> If people are going to implement system-level hacks to access D-VFS, I
> really do think the absolute best bet is to make open() recognize a  
> URI
> and start talking to the D-VFS daemon instead of the kernel.  Better
> performance, better compatibility with other D-VFS apps, and easier to
> port to other systems.  There are some problems with such an approach,
> but they're things I'm quite sure the Free Software community can
> tackle.  You're all a bright bunch.  ;-)

I don't think that Rosen meant any such thing. No system-level hacks,  
no messing with open(). What I understood he meant was that the  
shares, or those that are easily mountable (no need to do any special  
trickery to mount, for example, an sftp connection), are mounted  
under /vfs. This means that D-VFS aware apps would continue to use  
the D-VFS library to communicate with the daemon, but it now allows  
non-D-VFS aware apps to access the shares as well, though their mount  
points. If a mount point is not available, then I'll live. :-)

JP


--
God is dead, now the war shall never end.