Re: [RFC] gvfs connected servers

[David Zeuthen <david fubar dk>]

On Mon, 2008-10-06 at 10:37 +0200, Alexander Larsson wrote:
> > Fixing issue 3. is also needed for the gphoto2 backend to support
> > multiple storage heads
> > 
> >  http://bugzilla.gnome.org/show_bug.cgi?id=520123
> 
> I don't think there is a need for this to solve that bug. It could
> easily have two mounts for the same camera and still use only one
> connection to it internally.

[...]

> I don't like this. Its sensible to have both these volumes. Yes.
> However, I don't think its sensible to have different volumes pointing
> to the same mount. Its really a weird setup that I think is gonna throw
> a lot of people and cause problems. 

I'm not sure it's going to cause a lot of problems; the only users of
all the volume monitor stuff are Nautilus, gtk+, the panel; e.g. stuff
shipped with the OS as part of the G stack. 

(It's also true I'm suggesting to change the semantics a bit... but one
could also argue the semantics right now are unspecified.)

> Now, I don't have a perfect solution already, but lets discuss the
> possibilities here. The other approach would be to have different mounts
> for these two volumes. However, we want to share the backing mount
> (ssh://quad.local/) for them both, so this isn't ideal. 
> 
> What if we make the mounts for these volumes "virtual", pointing to
> their ancestor mount instead? Kinda like symlink mounts? 

I'm not sure what a symlink mount is...

> If we did that then to the above would be added a third GVolume, for the
> root GMount (ssh://quad.local). I think that is sane, since otherwise
> you wouldn't have anything anchoring that mount (i.e. no volume for the
> root location on ssh://quad.local).

But that is the situation right now; we currently don't have volumes
anchoring any of the current sftp/smb mounts etc. Btw, unanchored mounts
are fine; even in a world with connected servers we'd still want that
for transient mounts you only intend to use once and disconnect. One
use-case is that you're at a conference and connecting to a someone's
"Public Files" DAV share to get a single file; when you have the file
you disconnect from the machine. So we still want to support unanchored
mounts.

Hmm. I guess we could add GMount objects in the connected-server volume
monitor; it'd look like this

 GConnectedServerVolume ("Home dir on quad.local")
  GConnectedServerMount (root: sftp://quad.local/home/davidz)

 GConnectedServerVolume ("Movies on quad.local")
  GConnectedServerMount (root: sftp://quad.local/media/Movies)

 GDaemonMount (root: sftp://quad.local/)

There's at least two issues with this

 1. The file manager and file chooser would display three icons

     Home dir on quad.local
     Movies on quad.local
     sftp mount at quad.local

    where the last one only shows up with the former two are mounted.
    The thing here is that we don't want "sftp mount at quad.local" to
    be shown at all.

    We can get around that by making the file manager and the file
    chooser not show unanchored mounts if, and only if, there exists a
    volume with an activation root inside it.

 2. Not sure how if the various path bars (in the file manager and the
    file chooser) would stop working; with this setup we'd have mounts
    inside mounts, e.g.

    [[icon] sftp mount at quad.local] [home] [[icon] Home dir on quad.local]

    Hmm. I guess it would work. One way of finding out is just
    trying ;-). If it doesn't work we could probably just fix these
    issues.

Then again, it's not like what I'm proposing with my patch set is ideal;
the biggest problem I have with my patch set is that users of the volume
monitor API needs to use the volume details rather than the mount
details when processing a mount for a volume with an activation root.

With the revised proposal, e.g. creating GConnectedServer mount objects,
this would be a non-issue. So I like that better and it shouldn't be too
much work changing the patch set to do that. What do you think?

> I haven't looked at the code yet, as I want to get the behaviour right
> first.

Yeah, makes sense.

      David