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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list