Re: [RFC] gvfs connected servers

[Alexander Larsson <alexl redhat com>]

On Thu, 2008-10-09 at 09:49 -0400, David Zeuthen wrote:

> On Thu, 2008-10-09 at 11:23 +0200, Alexander Larsson wrote:
> > This is yet another separate daemon There is lots of daemons now. Maybe
> > we can combine some of the daemons that are basically always running?
> > I'm not sure what the overhead is atm, maybe we should measure it first.
> 
> It would probably be good to measure it first; who knows, maybe it's
> actually faster than a single daemon process given there's no contention
> for the main loop. I don't know. But IIRC, processes on Linux are as
> fast as threads. Then again, on e.g. ARM context switching is really
> expensive. But that's more of an ARM problem.
>
> Either way, that problem is probably orthogonal to this feature.

I was more thinking memory overhead, but yes, lets drop this for now.

> > +#define PATH_GCONF_CONNECTED_SERVERS
> > "/desktop/gnome/gvfs-connected-servers"
> > 
> > Why not use the old "connected_servers" configs?
> 
> I wasn't sure what these looked like. It's possible we could reuse them.
> But I'd rather not, I think the URI format from gnome-vfs to gvfs
> changed a bit.

There has been no changes in URI format to my knowledge.

Here is how it currently looks:
$ gconftool-2 -R /desktop/gnome/connected_servers
 /desktop/gnome/connected_servers/7:
  uri = sftp://172.31.0.13/
  icon = gnome-fs-ssh
  display_name = maurice
 /desktop/gnome/connected_servers/3:
  uri = smb://maurice/data
  icon = gnome-fs-smb
  display_name = smb-data
 /desktop/gnome/connected_servers/4:
 /desktop/gnome/connected_servers/6:
  uri = ftp://alex 192 168 0 101/Users/alex
  icon = gnome-fs-ftp
  display_name = OSX box

> > Don't we want the volume and mount to be able to have different icons?
> > So you can see its been mounted?
> 
> I don't think so. I think, for specifically for connected-server volumes
> that are not mounted, we should just attempt to mount the volume if we
> attempt to do IO. It might involve bringing up authentication dialogs;
> the operation might also fail. Not sure how hard this is to implement in
> Nautilus though, thoughts?

Shouldn't be that hard. I think it might more or less just work already.
We already mount on demand.

> (Also, if we were to use a separate icon, what would the icon be? Keep
> in mind that we want connected-server volumes to have user-configurable
> icons because we want these to be memorable. We want this because
> connected-server volumes represents a really important resource for the
> end user (e.g. "My Public Web Files" or "Accounts Payable" or "Project
> Mayhem File Server").

Yeah.

> > I'm not sure about the behaviour of the desktop icons here. We're on
> > purpose not showing volumes on the desktop but only mounts as desktop
> > space is rather tight, and we show the volumes in several other places
> > already to make it easy to mount them (side bar, computer:, panel places
> > menu). What makes the connected server volumes different from the other
> > unmounted volumes in the system?
> > 
> > I'd rather have a (default off) option to show all volumes on the
> > desktop. (The desktop is after all a very in-your-face thing, and
> > allowing a bunch of config options to tweak your use of it doesn't seem 
> > too excessive.)
> 
> Well, I guess there's two reasons here. First, Nautilus up until GNOME
> 2.22 showed connected servers on the desktop. Second, I grown to like
> that feature so that's why I made sure we got it back. In fact, the
> latter is why I'm working on these patches; I want my "public_html @
> fd.o" icon back!
> 
> More generally, I think the desktop icon is an useful feature because
> connected servers really represents an important resource (after all the
> user and/or administrator went out of their way to add it) and thus
> deserves a prominent location in the UI.
>
> Also, with the file manager automatically mounting connected-server
> volumes on demand (as discussed above), connected-server volumes are
> very similar to persistent mounts; for the end user they behave exactly
> that way. Thus, we should treat these volumes as persistent mounts in
> the UI, e.g. show them on the desktop just like we already show mounts.

Well, they are clearly not persistant if you need to log in when you
click on them, but I think I agree with your general point that we
should show them by default.