system and desktop VFS merged

[rosen georgiev]

Sean Middleditch wrote:

> On Sun, 2005-03-27 at 17:01 +0300, rosen georgiev wrote:
> 
> > So there should be :
> > 
> > a project to build the vfs layer, something like a set of librarys (eg
> > libvfsftp, libvfsftp, libvfsssh and so on) that, as sed manage the
> > connection reuse, passwords, security ... (this is something i'm not sure
> > can be done - is it possible to make eg. libvfsftp so that connect will
> > return the same connection for a set of processes, if they don't explicitly
> > ask for a new one?)
> 
> You must use a daemon, which we will be using no matter what, as it is
> simply impossible to provide the desirable semantics without one. The
> daemon can do all the magic of connection sharing, password querying and
> caching, file caching, whatever we need.

sorry, i didn't want to go there again :)
isn't it possible to make the libs a interface to the daemon (if not - skip the 
next 7 lines)
What i was thinking is that there should be a lib for every protocol used
giving almost the same functionality + the shareing of connections, 
passwords and ..., it should not be POSIX. Then D-VFS will use that to
implement its high level API, but there could also be other apps or APIs
that will use this "vfs layer" to give POSIX access - they are not part of 
D-VFS (may be there will be no such apps) and they will still share the 
connection.

> > 
> > and something to replace FUSE-KIO so that it uses the vfs layer and if 
> > possible cross patform (HURD will also be easy - but not very used :)
> 
> Adding a FUSE layer to work on top of D-VFS would be quite possible and
> something I fully expect to happen.
> 

Yes, but isn't it better (in means of speed) to have a FUSE fs that talks to 
the protocol it implements directly (throught the vfs layer) and not 
throught D-VFS

> 
> > 
> > 
> > It is obvious that this is not a complete cross platform solution but it
> > _can_ be if BSD and others make something like FUSE for there kernel and it
> > _does_ provide a complete Desktop VFS, the rest can be added in time

i didn't say that right, here is anothe try:
D-VFS will be crossplatfrom, but the connectivity with non-desktop apps 
will be available only on Linux throught FUSE-DVFS or something similar.

> 
> First, and I've said this more times than I ever cared for, FUSE is NOT
> THE ANSWER, and NEVER WILL BE. FUSE is 100% limited to working with
> POSIX, and POSIX only, and cannot offer functionality in addition to
> POSIX, and that isn't acceptable, because POSIX simply CANNOT do certain
> things we want. Simple things like "copy this file" cannot be done with
> POSIX - you must instead read/stream the file from the source to the
> destination - on a remote share, that means in order to copy a file
> (which could otherwise be done 100% on the server-end) you must download
> the entire file and then upload it back, just to make a copy. POSIX
> isn't up to snuff, FUSE can only offer POSIX, and thus FUSE is not the
> answer. It's a great hack to make legacy apps work somewhat well with
> modern file system operations, but it is not and never, ever should be
> the basis of a modern VFS layer.
> 
> I fully support a FUSE module for D-VFS, but I will not see D-VFS get
> hamstrung by being designed entirely around FUSE and its limitations.
> 

i wasn't saying that FUSE is the answer, but it could be the answer for the
legacy apps that Desktop apps call (the IDE/gcc case). FUSE things are
not part of D-VFS and are not mandatory on a system.

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
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?


still eager :)

rosen

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