system and desktop VFS merged

[rosen georgiev]

so /vfs was not a good idea for reasons that i overlooked
Lars Hallberg wrote:
> But i think the /vfs structure have problems. What if more than one user 
> mount ther home directory over the same protocoll from the same server? 
> Then we need username in the pathname.

or would never think of:
Diego Calleja wrote:
> The idea of /vfs/protocol is just against the idea of userspace filesystems. I mean, the
> whole purpose of a userspace filesystem should be being *completely* transparent
> If you're going to do /vfs/protocol, what's the point in using the filesystem namespace for
> it, except for tyding it? What would be next, require the path to be in valid utf-8?

but if its ~/vfs 
(the idea is from)
Lars Hallberg wrote:
> It would be cool if stuff i conect to over VFS turns upp in the 
> filsystem to for old apps and tool like find. But I realy expect them to 
> turn upp ass:
> ~/vfs/protocl/server/path
>

and i stop calling the 2 (not 3 anymore) things "standards" (i just
fancy the word ;) both of them (what i overlooked) are OK, right?

we don't need 3 (the signal sending) because the only thing that would
be mounted at ~/vfs is gonna be something like FUSE-DVFS - not an
automounter (who would deal with every protocol separetly). Something
useing DVFS, so that it reuses sessions and all the rest.

All that D-VFS needs to provide are two functions:
- one than is internal to the API that converts paths, all API functions
like LoadFile, MoveFolder or whatever you will call them, will use it
internaly to get the "real" path (i guess this will be the URI form).
if i'm not missing something this is very easy to do: get the username
and concatenate some strings.
- the other function will be a API function used be developers who in
there D-VFS apps call other apps (maybe not D-VFS). it returns a 
path in the form ~/vfs/.... I personaly will be satisfyed even if only 
filebrowsers implement this.

these functions are so simple that they could be #define-d to do no work
when compileing D-VFS for platforms that can't make use of this eg. BSD.
You can even remove the functionality they give when/if someday
the hacks on libc's open( ) are working - noone will notice then

i'm sure you will have noting against gnomevfs and KIO beeing ported
to rely on D-VFS. for faster and more painless transition. They will be 
something like another API for the D-VFS daemon. The two funcs
will simpy aid the integration of POSIX API for D-VFS daemon. This
will provide complete user transparentci, that is not available now
(people will not need to go to a shell and call mount when they 
find a file on a remote share, it will be totaly transparent to them
if they have FUSE-DVFS mounted.)

so in short:
- all the extra work in D-VFS are the two functions, and encourageing
  developers to use the second one
- the ~/vfs is something that the user decides if he needs it. it may
  not exist at all.
- the FUSE-DVFS is a separete project, wich may never happen


Sean Middleditch wrote:
> Design ugliness, yes. It's over-complicated and isn't necessary. D-VFS
> should not bend over backwards to work for apps that *should* just
> update to the newer API. If people want to implement FUSE backends or
> other hacks to help legacy apps, that's great, I'm all for that. But
> that should be orthogonal to D-VFS, so that when the important apps are
> all ported over, the hacks can disappear and nobody will know, and we
> won't be stuck supporting APIs and system we already know aren't good
> enough 10, 20 years down the road.
> 
aren't your requirements met with _this_ design - except ugliness that is 
seen only by D-VFS developers.


rosen


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