Re: [RFC] gvfs connected servers
- From: David Zeuthen <david fubar dk>
- To: Alexander Larsson <alexl redhat com>
- Cc: gvfs-list gnome org, mclasen redhat com
- Subject: Re: [RFC] gvfs connected servers
- Date: Thu, 09 Oct 2008 09:49:00 -0400
Hi,
Will follow up on patch feedback in Bugzilla; only addressing the
high-level points here.
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.
If we find the overhead is excessive, one possible solution would be to
annotate the .service files and teach the bus daemon about using an
activation helper; e.g. instead of launching the given binary, the bus
daemon would send a message to a well-known name asking it to activate
another given well-known name. I remember people asking about something
like this on dbus-list, it's worth checking out the archives.
Either way, that problem is probably orthogonal to this feature.
> +#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.
> 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?
(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").
> 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.
David
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]