libhal-storage

David Zeuthen david at fubar.dk
Thu Sep 23 13:08:12 PDT 2004


Hey,

I recently committed the initial version of libhal-storage to hal CVS as
described in the end of this message

http://mail.gnome.org/archives/utopia-list/2004-August/msg00096.html

This library serves the following two purposes

1. C-based API for accessing what HAL knows about storage devices
   and volumes; e.g. you no longer need to use the somewhat fragile
   and tedious string-based property API. Which is nice.

2. Sharing of naming and icon selection policy; this implies that
   this library is subject to l10n. I've already prepared it for
   i18n and even added danish translations :-)

    [/me hopes he got the l10n and i18n terms right :-)]

The following things was taking into consideration when designing the
library

a. Must be easy to bind to various languages/frameworks such as 
   Qt, GTK+, Python etc.

b. Efficient; the library uses the hal_device_get_all_properties so
    the amount of roundtrips is much minimized

c. Easy to use and type safe; follow library best practices like libhal
   such as opaque datatypes, namespace prefixing, package-config file 
   and so on.

d. Policy is configurable to a certain degree.

e. Only depend on libhal, libdbus and libc

Check it out

  http://freedesktop.org/cgi-bin/viewcvs.cgi/hal/hal/libhal-storage/libhal-storage.h?rev=1.1&view=auto

This is an early version; I expect to use it in both GNOME VFS and
fstab-sync so the API will evolve over time. It would make good sense to
use it in g-v-m and k-v-m as well. Specifically more policy stuff like
"does the volume contain photos", "is this a Video DVD", "is this a VCD"
etc. would make sense to put in here. Which means more sharing of code.
Which is nice.

So, I don't expect this library to be 100% stable in the next few
months; on the other hand I don't expect the existing API to change a
lot. It also needs some more (Doxygen) documentation but if you're
familiar with HAL it should be straightforward to use.

Another thought I had was this: Perhaps this library should expose
functions like hal_volume_set_label(), hal_volume_mount(),
hal_volume_unmount() etc. This will in many ways close the loop; e.g.
provide full abstraction of various storage devices and volumes in the
system. I like that.

Comments are welcome.

Cheers,
David

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list