HAL 0.1 release

[David Zeuthen]

On Wed, 2003-10-01 at 21:31, Joe Shaw wrote:
> On Wed, 2003-10-01 at 15:01, Havoc Pennington wrote:
> > Of course having wrapper APIs or "bindings" for various dependencies is
> > fine, see dbus (and the yes/no/auto --enable-foo setup for each
> > dependency foo in the configure script).
> 
> Speaking of which, do you think it's possible and sensible to split some
> common things in dbus out into a library?  I'm thinking of a lot of
> stuff that is reinvented in dbus that exists in glib, like string
> utilities, DBusWatch, etc.  If it's decided to forego a glib dependency
> in the client library for hal, we'll need some main loop integration for
> getting hardware events.  Right now I think it just assumes a glib main
> loop or does the dbus stuff in a separate thread.  (David, correct me if
> I'm wrong.)
> 

For the library it's only d-bus. Mainloop integration is the
responsibility of the application using it (through the app setting it
in a callback [1]). Not a big deal if you use glib or Qt. 

(But it would be very useful to have sample code or a library doing main
loop integration, e.g. DBusWatch).

Re strings and dictionaries I wrote some naive O(n) implementation
myself, but that might not even be neccessary if we chose to not cache
anything in the application, but instead use d-bus calls for
get|set_property etc. Right now *everything* is cached per application.
Which is, ahem, not very smart.

So, in that case we will have less footprint per application, but higher
latency. But d-bus latency is quite good, right? And we don't really
change properties so often. The best solution might be a hybrid. 

I was thinking of just taking the strings and dictionary code from d-bus
actually :-)

Cheers,
David

[1] : See a simple app using libhal here
http://x2.freedesktop.org/cgi-bin/cvsweb/hal/hal/hal_set_property/hal_set_property.c?rev=1.1&content-type=text/x-cvsweb-markup