VFS for legacy apps (was: gvfs status report)

[Hans Petter Jansson <hpj novell com>]

On Tue, 2007-02-20 at 09:24 +0100, Alexander Larsson wrote:

[Snip]

> In general, the way mountpoints work in unix is that they are mounted
> over *one* directory, and don't mix things up with other mounts, so I
> think the best solution would be to have each mountpoint be one
> subdirectory under ~/.mounts (or whatever). 
> 
> The question is then, how do we name these subdirectories. I've come up
> with two plausible versions. One, we use the full mount specification
> and encode it (with escaping) in the mountpoint name. So, you'd have 
> ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt.
> 
> Two, each mountpoint generates a display name that is used in the gui
> for the mountpoint. An example for smb would be "$share share at
> $server". This is weakly unique[1] on the same machine. We can make it
> guaranteed unique in the daemon and use this as the mountpoint name.
> Like this
> ~/.mount/$share share at $server/dir/file.txt. 
> 
> The second method isn't really possible to map backwards to the original
> source of the mountpoint if the mountpoint is not mounted. However in
> almost all cases where we access a file from it, it will be mounted
> already, and thus mapped in the same place. So this isn't really a
> problem in practice, especially since the desktop itself natively
> handles gvfs mounts. And if its not mounted you can easily display a
> warning that "$share share at $server" isn't mounted which is nice and
> readable. This isn't really all that different to traditional unix
> mounts. For instance you can't map from a nfs mountpoint
> like /mnt/bigserver to the exact nfs details of the mounpoint (if its
> not mounted).

This won't work. We need to be able to extract all the mount information
from the path, so that if the app stores the path across sessions, say,
in "recent documents", the FUSE layer will know what to do when it's
accessed later.

However, the first method you describe:

~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt

sounds perfect. It's rich (we can get back the mount info later),
extensible (we don't have to figure out the entire set of potential
mount options in advance) and fairly simple (the root nodes are all
direct children of ~/.mounts).

> The advantage of method one is that you can actually take such a path
> and extract enought information to mount the path. On the other hand, it
> looks like total ass. Pray that it doesn't show up in the UI somewhere.

Most URIs also look like total ass. It depends on what you're used to.
And ass or not, being able to access a document on a remote share when
it's launched with or dragged to a legacy app trumps it. I'm sure users
of e.g. MPlayer or Acroread would thank us. There are also plenty of
GNOME apps that never worked with non-local files :)

-- 
Hans Petter