Re: Removable media management

[David Zeuthen <david fubar dk>]

On Wed, 2008-05-28 at 09:36 +0200, Peter Bauer wrote:
> I can't get a survey of what GFVS is. GnomeVFS is deprecated, but the
> documentation doesn't tell something about a replacement or an
> alternative: http://library.gnome.org/devel/references

See the "Migrating to GIO" section near the bottom of the GIO docs

http://library.gnome.org/devel/gio/unstable/

> So I assume GVFS is again some collection of libraries. I suggest GIO is
> at least part of it.

GIO (part of glib) is the interface applications will use instead of
GnomeVFS and GVFS is a set of plug-ins that enhance gio (for example to
provide more file systems / better volume monitoring).

> As far as I could understand DeviceKit isn't a gnome specific approach
> (which is of course not bad!). And the API documentation from DeviceKit
> http://hal.freedesktop.org/docs/DeviceKit/
> is either far from being complete or DeviceKit is not yet complete.

DeviceKit is a) not yet complete; b) the successor to HAL; c) written by
the same team that does HAL; d) a simple mechanism to enumerate devices
and do operations on them. So it's natural to replace the HAL dep in
gvfs and Nautilus with a DeviceKit one.

> Isn't easier to extend GIO API? See this:
> http://library.gnome.org/devel/gio/unstable/GDrive.html 
> wouldn't it be nice to have a function like g_drive_set_name next to
> g_drive_get_name?
> 
> And also some functions like
> g_drive_get_fs_status  //!< check if filesystem was properly unmounted
> g_drive_check_fs       //!< perform filesystem check where applicable 
> g_drive_check_fs_on_next_boot  //!< ...
> g_drive_get_fsck_period //!< where applicable...
> g_drive_set_fsck_period //!< where applicable...
> g_drive_format_filesystem //!< don't change partition, just format it

If we want to do this, these functions will have to be on GVolume rather
than GDrive. But keep in mind that gio/gvfs handles much more than just
block devices. For example fsck, format etc. makes little or no sense on
sftp, gphoto2, obex-ftp etc. file systems.

> Or should this functionality be part of another library? Maybe all this
> should be discussed elsewhere. But wouldn't be nice for the nautilus
> team?

My plan is to provide a set of GObject based libraries (one library at
the glib-level (no gtk deps) and one library at the gtk-level for
dialogs and widgets) to do this for block devices.. most of this is
already done; just need to factor the code out into libraries

http://gitweb.freedesktop.org/?p=users/david/gnome-disk-utility.git;a=tree;h=cd9c348a5188c28adc0cd541e3dec9c3e0ddf493;hb=9380c678b44cad4f8b06e0c4dd45029db36177b9;f=src

So.. we could abstract this in GIO just like we abstract bits of it
including mounting/unmounting/ejecting (e.g. add API to GDrive, GVolume,
GMount). But I'm just not sure it's worth it.. it would add a lot of
complexity to API's that we can never change... and given that the only
realistic consumer of this API is Nautilus it seems like a lot of extra
work for no gain.

The only situation where it *might* make sense to do this is if a gvfs
filesystem driver can offer similar functionality; e.g. a way to format
the media / change the fs label. If it turns out this is the case, we
can always build the abstraction and (for block devices) just call into
the g-d-u libraries I'm working on.

       David