[Fwd: Re: gio changes for GVolume and GDrive]

[Alexander Larsson <alexl redhat com>]

It seems davidz:s mail didn't reach the list. Here is a CC:ed copy.

--- Begin Message ---

• From: David Zeuthen <david fubar dk>
• To: Alexander Larsson <alexl redhat com>
• Cc: gtk-devel-list gnome org
• Subject: Re: gio changes for GVolume and GDrive
• Date: Tue, 11 Dec 2007 09:50:27 -0500

On Tue, 2007-12-11 at 12:51 +0100, Alexander Larsson wrote:
> On Tue, 2007-12-11 at 04:11 -0500, David Zeuthen wrote:
> > Hi,
> > 
> > I've started working on writing a hal implementation for GVolumeMonitor
> > and have some suggestions making the volume monitor API better. First of
> > all it appears that the current GDrive and GVolume abstraction is more
> > or less a 1:1 copy of what was in GnomeVFS. 
> > 
> > There's a couple of problems with this approach. The main problem is
> > that GDrive doesn't really represent a drive. It represents a mountable
> > volume; typically such as partitions on a hard drive or entries in the
> > classic /etc/fstab file. This breaks down if you have media with
> > multiple partitions or mixed optical discs.
> > 
> > So part of this patch renames GDrive to GMountableVolume. Then we
> > reintroduce GDrive as a new interface that more precisely represents
> > what most people associate with the word ''drive'': a collection of
> > mountable volumes and the notion of media.
> 
> In general I like this approach, however, the names just don't work for
> me. GMountableVolume is kinda weird (is it a volume too? then why isn't
> it a GVolume?). 

Yeah. Naming is hard.

> Also, if we start from a more physical definition i'd
> say that a partition on a disk is a volume, not abstract "mounted
> partition" os entity.

I actually think the word "volume" captures what the class current
represents; e.g. a directory subtree /mountpoint of the namespace where
the contents all stem from some (possibly mountable) entity that is
mounted into said name space.

(where name space can either be the (file://)/ UNIX name space or the
uri: name space used by gio.)

> 
> So, Maybe a better set of names would be something like:
> GDrive <-1-n-> GVolume <-1-1-> GMount
> 
> Other alternatives for GMount: GMountedVolume, GMounted, GMountPoint
> Any other ideas?

It's going to suck renaming GVolume (since it's used in a lot of places)
so a solution that only changes the intermediate one would be
preferable. Is GMountable too abstract?

GDrive <-1-n-> GMountable <-1-1-> GVolume

This fits nicely into that given a GMountable you call mount() to get
the GVolume. Now a GVolume may or may not have a GMountable (or even a
GDrive); situations where there is no GMountable includes 

 - network mounts
 - bluetooth phones
 - gphoto2 drive cameras
 - burn:///
 - audiocd:///
 - user-space-vfat-driver:///

though of course any of these implementations are free to provide a
dummy GMountable where can_mount() returns FALSE if it makes it easier
to implement and there's a GDrive in the picture. Or if they want they
can implement mounting (with whatever semantics that entails).

All that kinda depends.. I guess ideally we avoid one can avoid the
concept of mounting/unmounting one should.

But I digress.

(Btw, do we want a get_volumes() method on GDrive? Right now there's
only a get_mountable_volumes() method (meaning that if you want GDrive
you need to have GMountableVolume's))

> > There's also a some new API in gunixmounts.c that I needed for both
> > backends. Thoughts? Also, I'm wondering, with these additions, if we can
> > do away with GUnixMountType altogether; it's pretty much an eyesore.
> 
> You want guess_icon to return a GIcon so we can do icon fallbacks. I
> agree that we should drop the GUnixMountType in the visible API. Its
> just not something you can trust further than guessing icons/names, and
> thats now availible in the API (with your patch).

Cool, I can fix that up too. Btw, I don't know how to properly and
effeciently implement 

 g_unix_get_canonical_device_path()

on other UNIX-like OS'es than Linux 2.6 + recent udev (the naive
implementation would be O(n) in number of items /dev including
stat(2)'ing device files and look for labels - the impl in my patch is
O(1) and no device access is needed). 

Maybe I should just remove it from the glib patch? Thinking more about
it I don't actually need it in the hal impl. either.

    David

--- End Message ---