system and desktop VFS merged

[rosen georgiev]

OK, no libs for each protocol over the daemon. that was not my target
area anyway :)
but i will continue argueing about the 2 stds (now becoming 3)

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.

coz it will make auto mounting easyer
here is an example how i hope it would work:
i'm browsing a share (eg smb://serv43/part04) in a D-VFS filemanager i
find a movie i want to check/see without copying it to my pc.
xine, mplayer ... don't support D-VFS yet. but the file argument that
(eg.) xine is started with is /vfs/smb/serv43/part04/<path to the movie>
so if i have FUSE-DVFS mounted at /vfs all is working and i'm happy.

actualy D-VFS also needs to inform (maybe with a D-BUS signal) 
everyone interested when the D-VFS daemon opens a connection
to somewhere. Then another daemon (not part of D-VFS at all)
who listens for that signal could ishue a mount call and the relevant 
thing will be available under /vfs. 

> 
> 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. ;-)
> 

ammm ... no system-level hacks, it sound too time consumeing

> 
> > 2) All programs that use a Desktop VFS and spawn processes
> > must give them the absolute path (/vfst/protocol/<path>). except
> > for the file:// protocol in this case file://<path> will be just <path>
> > 
> > The files under /vfs will be owned by the user who accessed them
> > and that is save enough right?
> 
> I don't think there's any real security problem with a /vfs system.
> Just general ugliness. ;-)
> 

but it makes *so many* things *so easy*. and nobody will actualy know
about them except the D-VFS developers. well app developers will
need to know about "2)" . but just give them a function to convert to 
the full path and they have nothing to complain about.

is the reason for rejecting them just it's "ugliness" !?

rosen


-----------------------------------------------------------------
http://gbg.bg/search - Изпробвайте още сега най-добрата българска търсачка!