Re: Hal script to index removable storage medium ?

["Joe Shaw" <joe joeshaw org>]

Hi,

On Thu, Jul 10, 2008 at 9:03 AM, D Bera <dbera web gmail com> wrote:
>  I am not much familiar with HAL scripts and how the nice popups
> "Open the Audio CD in Amarok" shows up when I insert an audio cd.

Essentially what happens is that when you attach a device, HAL notices
through the hotplug mechanisms and instantiates a HAL device object
which represents the hardware.  Some standard properties are added
based on the bus, type of device, etc., and then scripts are run to
set additional properties or set policies.

Once the device is added in HAL, it emits D-Bus signals on the system
bus.  The main ones that Beagle would care about would be DeviceAdded
and DeviceRemoved, and possibly also NewCapability and LostCapability.

The popup dialogs you see in GNOME or KDE are desktop-specific policy
pieces.  On GNOME, this is handled by gnome-volume-manager.  It sees
the added and removed signals, and performs some action (ie, policy)
based on configuration.  It's a good piece of code to use as an
example for this because Beagle will care about a lot of the same
things.

I forget if GVM itself emits signals on the session bus when file
systems are mounted... it seems like it would have...  If it doesn't,
I suspect they'd take a patch to add it.

> I am thinking something along the same lines:
>
> (1) When the medium is inserted, if it of the "right kind", then show
> the option "Index and search this medium".

It would probably make sense to put this in GVM, or else you would
probably have two separate (but related) dialogs popping up.  Then
other services like Tracker could use it.  The downside is that you'd
also have to implement similar functionality a second time (for KDE,
or for GNOME if you did KDE first).

Another option is to put this in the Beagle UI -- I can imagine a
notification window popping up asking if the user wants to index the
volume.  Plus side to this is that works across all desktops.

> (3) If the medium is writable then create a .beagleindex directory in
> the medium's root directory; if the directory already exists then skip
> this step
> (4) If the medium is not writable, inform the user and ask for a
> separate location to store the index

I think the determination has to be more nuanced than
writable/non-writable.  You probably don't want to be storing indexes
on flash drives.  HAL's properties should make it a little easier to
figure out which is which, but a blunt way would be to assume that
anything > 8 GB is a hard drive and anything smaller is flash.

> (5) If the indexdirectory already contains RemovableIndex.xml (which
> is a sign that a previous index already exists), then call
> "beagle-removable-index --mount..." followed by
> "beagle-removable-index --removable..."; otherwise call
> "beagle-build-index --removable.." and then run
> "beagle-removable-index --mount..."
> (6) Running beagled will automatically add this index to its search
> list and pick up changes as beagle-build-index finds new files

You could do these, but it almost seems like it would make more sense
to move all of this functionality into beagled itself, since (at least
in theory) it'll always be running and can catch these signals.

> (7) (is this doable with HAL ?) When unmounting,
> "beagle-removable-index --unmount..." needs to be called - the index
> will be dropped from beagled's list and all open files in the
> removable medium will be closed

There are definitely mount/unmount signals, but I don't recall if they
come from HAL or from GVM/KDE-equivalent.  There are hooks in the
kernel (called uevents) which tell userspace when an event happens.
When Robert and I worked on Project Utopia the first thing we did was
add uevents for mount/unmount and got HAL to listen to them.  So you
should get these signals even if someone unmounts a device by hand.
On the other hand, there's a possibility that the power goes out and
the signal is never received, so I'm not sure you can depend on them
reliably.

Hope this helps,
Joe