system and desktop VFS merged
spam at micropp.se
Sun Mar 27 21:11:55 EEST 2005
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:
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
>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
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 :-)
More information about the xdg