system and desktop VFS merged

[Lars Hallberg]

rosen georgiev wrote:

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

Wher only I have permisions to ~/vfs.

I defenitly do *not* expect other user to be able to acces my files on a 
remot server just becose I access them thru VFS!!!

>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>
>  
>
Make sens that VFS avare app recognise buth uri and the 'special' vfs 
filepath. And it make sens to use the later in IPC (when passable) so 
old apps work to in the case a filsystem interface is avalible for that 
protocoll/platform.

>3)	The Desktop VFS API must always use the vfs layer!
>  
>
Not sure what Youy mean but I can't ses any reson for a VFS avare app 
not to talk directly to the VFS-deamon in case they detect a uri or 
vfs-path.

====================
Completly different VFS isue
====================

Vould it be passeble to export 'extra' capabiliitys for protokol that 
suport it? Thinking about ssh, that suport remot execution. For example, 
a filbrowser could ask: "run local or remote?" when ju click an 
executable in a sshfs folder. That vould provide the *right* solution to 
the IDE case to - run make on the server with the sorce!

Some CLI access to this, kind of liks fsh, vould be cool. A ssh vfs 
backend that simply integrate with fsh maybe :-)

/LaH