Re: [gfvs] cdda backend

[Alexander Larsson <alexl redhat com>]

On Mon, 2007-12-17 at 18:07 -0500, David Zeuthen wrote:
> > 
> > You don't actually have to make each cdda mount its own process. If you
> > want you can add a well-known dbus name to the cdda.mount.in file (which
> > is missing from your patch btw). gvfsd will hand off cdda mount
> > operations to that name if it exists, instead of spawning a new copy.
> 
> But I actually want a separate process for each mounted disc... seems
> easier if I don't have to care about life cycle management at all (e.g.
> when unmounted gvfsd will terminate the backend process).

Oh, you don't have to do that. Mounting will automatically create new
GVfsBackend objects and add them to the GVfsDaemon object, unmounting
will remove them. When there are no left it will exit.

> > Hmmm. Tricky. Its kinda weird having the name of the actual mountpoint
> > change. Especially with it being the identifier for the mount in the
> > fuse case. I think the best solution is to have the volume be called
> > _("Audio Disc"), but then set the display name of the root of the disk
> > to the actual disk title. Thats what will be displayed in many places
> > like the window title for the toplevel directory.
> 
> Maybe we want
> 
>  g_vfs_backend_set_display_name (backend, display_name);
>  g_vfs_backend_set_local_mount_name (backend, display_name); [1]
> 
> where the latter can't change once mounted and is used by the FUSE
> daemon. The latter can change as much as we want (AFAICT it's fine to
> have collisions in displayable names for both GDrive, GVolume and
> GMount.)
>
> [1] : If not apparent already, I suck at naming. Feel free to suggest
> alternatives

Yeah, this seems like a good idea.
Maybe g_vfs_backend_set_stable_name()?

> > I don't see an obvious easy solution. It requires some work. The ideal
> > thing to match with is an GMountSpec (which is basically the set of
> > key-value pairs that define a gvfs mount). For a GDaemonMount this is
> > availible in the GMountInfo object.
> > 
> > Thats a gvfs-specific object though, so we can't make that availible in
> > the base GVolume apis. What if we add some new vtable calls in
> > GVolumeMonitor like find_volume_for_new_mount() and
> > find_mount_for_new_volume() which we have GUnionVolumeMonitor call on
> > the installed backends when new, unowned volume/mounts are added.
> 
> Yeah, that sounds pretty good. There's some details on how to uniquely
> identify the volume (using display_name is not enough; uuid may be if we
> can guarantee that one is available. Not sure.). I'll look into this and
> will send a patch.

Thats up to each backend, right? the gvfs backend should use the
GMountSpec to identify the volume.