Whilst integrating freedesktop HAL into the volume monitor daemon of gnome-vfs
I've come across a few deficiencies in the API. 

There appears to be a one-to-one correspondance between GnomeVFSDrive and
GnomeVFSVolume objects that probably stems from the current detection code e.g.
reading and monitoring /etc/fstab and /etc/mtab ish files. Further, a
GnomeVFSDrive expects a mount point (through the activation URI) and a block
device that is a partition, e.g. /dev/sda1.

In order to support hardware where polling (the kernel won't poll for us, check
linux-hotplug and linux-kernel archives from Q1 2004) for media doesn't work
(try a Compact Flash 16-bit PCMCIA reader on a Linux 2.6.6 kernel for instance),
it is proposed to change GnomeVFSDrive such that it accepts a top-level block
device, e.g. /dev/sda. 

When activating this top-level block device (clicking on it in Nautilus for
instance) gnome-vfs should poll for media (effectively a 'blockdev --rereadpt
/dev/sda') and then the partitions will appear through a hotplug mechanism and
middleware, like HAL or updfstab(1) will create /etc/fstab.

Second, there should be a 1 to many (where many is 0, 1, 2, ...) relationship
between GnomeVFSDrive and GnomeVFSVolume as one top-level block device may have
several partitions embedded.

I'm not sure what the implications for the UI in Nautilus will be (consider
plugging a Compact Flash card with two partitions into a card reader and then
clicking on the drive representing the card reader; now two volumes will appear
and will the drive go away?) or whether this API change could be backwards
compatible.

Please advise, Thanks,
David