Re: [gfvs] cdda backend

[David Zeuthen <david fubar dk>]

On Thu, 2007-12-20 at 11:57 +0100, Alexander Larsson wrote:
> So, I guess the question is, in what way is it better to have
> "public_html @ p.fd.o" be a volume than using a bookmark for this?

I suppose either works; it was just an idea. The main advantage is that
the icon for the volume wouldn't jump around (bookmarks IIRC are stored
below a separator line in the file chooser and sidebar) if you double
click it in the file chooser. I think bookmarks are more intended for
files or folders? I don't know.

> >  gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter,
> >                                                GMount *orphan);
> > 
> > that each implementation can implement? Alternatively we can put this
> > method on the GMount interface but that seems wrong since it's only
> > something volume monitors would ever want to do.
> 
> The volume monitor would recurse over all volumes and call this?
> 
> Isn't it better to have something like: 
> 
>  GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor,
>                                              GVolume *adopter)

Actually with the proposal I had, the adoptor itself would iterate over
all mounts and use it's own criteria of how to pick an orphan - it's
probably in a better position to choose than the orphan's volume
monitor? I mean, suppose we did "fav servers" as a GVolume stemming from
a "fav servers" volume monitor; how would GDaemonVolumeMonitor know how
to pick adopter? 

(OTOH, the "fav servers" volume monitor backend would have no problem
picking the orphan; it would just compare the get_mount_root() from each
GMount on the system with whatever preferences it relies on)

<stuff about busy unmount dialog>

> I really think you are overreacting a bit on this. For regular unix
> mounts it is often the case that you get stuck with busy mounts, because
> applications with cwd inside the mount keep it open, or due to a dnotify
> watch. However, for gvfs mounts the only time something is busy is if
> there is actually an ongoing operation like a file copy, loading a file
> or something like that. This is far less likely to happen when you
> unmount a volume, and its far easier to be aware of this (for instance
> you'd have a copy file progress notification icon for the file copy, or
> just loading a file in gedit).
>
> Furthermore, since we can make sure we can succeed 100% with a forced
> unmount, having a blunt instrument like killing an application that is
> doing an operation on the volume seems like the wrong thing to do. I
> can't think of any reason you'd want to do this instead of forcefully
> unmounting and have the apps doing the operation get an i/o error.
> 
> So, adding this chunk of lowlevel weird stuff (where you have to expose
> nonportable things like pids, etc) to the supported portable highlevel
> API for this very rare case that we can handle well with a force unmount
> anyway seems like a bad idea.
> 
> Now, maybe you're thinking of using this for unmounting in the hal
> backend were we're talking about unmounting unix filesystems, which do
> not support a nice force unmount and are more likely to be busy. Yes,
> this is more of a problem, but do we really need to expose the
> implementation of lsof in the highlevel API. Isn't it better to just
> encapsulate the whole thing (dialog/widget + getting the data for it) in
> a single call.

Sure, we can do that as well (putting the calls to lsof(8) into the code
creating the dialog). It just seems like a waste to not abstract this
stuff out. There's GPid in glib already so am not sure why this isn't
portable (list_open_files() would be allowed to error out with
G_IO_ERROR_NOT_SUPPORTED of course).

Btw, I wouldn't be so sure about busy mounts; what if you keep you
media collection on a networked share? People are working on moving
people's documents and media off the client and on to hosted storage
services; it seems we'll be getting more of this. (And you can cwd into
~/.gvfs too but I agree that is not so common).

> > <stuff about volume monitoring>

> If you want to extend this goal, you need to describe exactly what is
> the target of the new API. What should you be able to do with it, and
> what not. Then we can discuss how this is best achieved.

Sure, in addition from the gio volume monitoring just being a utility
library to be used by the file manager and file chooser, I'd like it to
be useful for other things.

First is auto mounters like e.g. gnome-volume-manager. This is necessary
because some file systems for devices like cameras and audio cd's are
not handled by hal (e.g. cdda:// and gphoto2://). So the auto mounter
needs to at least pay attention to the volume monitor to mount a gphoto2
camera and a cdda disc.

The other thing the auto mounter does is prompt the user for what
application to run when media with well-known content is inserted (cf.
this http://people.freedesktop.org/~david/g-v-m-prefs.png ). Hence you
need to have an idea of what could be on the media - similar to
the similar to g_mount_guess_content_type() in my patch. Also, since
"what could be on the media" is not standardized the user is left with
text entry box for selecting the app to use.

Then you have the apps; let's review how they work. Here's the media on
currently on my box

 http://people.freedesktop.org/~david/my-media.png

Here's the f-spot import dialog

 http://people.freedesktop.org/~david/f-spot%20import.png

and the Banshee one

 http://people.freedesktop.org/~david/banshee%20import.png

Observations

 - None of the dialogs show 1.0GB media; this is because they
   scan the media for content (similar to g_mount_guess_content_type()
   in my patch). I guess each app (and g-v-m) and their own
   heuristics on how to do this.

 - the f-spot dialog shows a gphoto2 camera connected; probably lots
   of pain involved in wrapping gphoto2 themselves instead of
   just using a modern VFS

 - so f-spot also shows the data disc; probably because there are
   pictures on it

 - Banshee shows my iPod but uses a different name and icon for it.

The rationale for the patch is to

 - define "what could be on the media" means (x-content/*)
 - unify all sniffing code into a single place
   - likely pluggable so 3rd party libs (like libipoddevice), that
     actually handle dealing with the device in question, can
     participate
     - involves name and icon selection too
 - encourage people to use (and write) gvfs backends instead of using
   Linux/UNIX-only libraries in their apps thus rendering non-portable

Because, right now, it's a mess and every app (including the auto
mounter) does their own thing. The result, as you can see from the
screenshots, is that things not only look different, the names are
different too. (and ideally, there would be a stock "select_media"
dialog where you pass one or more x-content/* identifiers.)

Of course, it's fine if this is not a goal for gio but then volume
monitor API of gio isn't really useful outside the file manager and the
file chooser and should perhaps be private API instead.

     David