Re: gvfs status report



On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote:

> In general I think that we will still use URIs to pass file references
> between apps when doing things like DnD, cut-and-paste or when saving
> filenames in config files. It seems hard to change this at this time,
> and it has some advantages in that other applications also understand
> such URIs (to some extent, vfs uris aren't always exactly like web
> uris). However, internally in gio we immediately map the URI to a
> mountpoint spec (which might not be mounted yet) and a path, and all
> path operations happens in this form. Think of URIs like a
> serialization form.
> 
> The mapping from uri to mount spec is done by custom backend-specific
> code. I arrived at this model after several false starts, and I think
> its pretty nice. It  means the backends and the client implementation
> get a very clean view of the world, and all the weirdness of strange
> URI schemes like smb is handled totally in one place in the client
> library code.
> 
> A large problem with gnome-vfs is that applications not specially
> coded to use gnome-vfs will not be able to read non-local files. A
> nice solution to this would be to use FUSE to let such apps use normal
> syscalls to access the files. In general its quite tricky to map any
> URI to a FUSE file, but with the mountpoint + filename setup gvfs uses
> it is very easy to create a FUSE filesystem that lets you access all
> the current vfs mounts. 

Could we standardize the local file system paths for non-gvfs apps, so
we can reliably DnD to them and have them receive local paths? E.g.

~/.mounts/<protocol>/<server>/<path>

Consider also apps that receive these local paths, store them and
reference them in future sessions.

I think it would be wise to include such functionality, or at least
specifications, if we're going to replace gnome-vfs anyway. It would
save worlds of pain in scenarios involving legacy or 3rd party apps.

Having these paths map 1:1 to URIs (with translation functions?) would
be excellent. It seems you've given it some thought - what are the
tricky parts?

-- 
Hans Petter




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]