hal draft spec

[David Zeuthen]

On Fri, 2003-09-12 at 19:09, George wrote:
> Are there going to be so many added/removed messages that it would be a
> problem to just get them all and filter them?  How many events can
> realistically happen in a given timeframe.
> 

Currently hald broadcast each and every change in the device database to
libhal using the dbus broadcast facilities. If we are to do unicast to
each libhal instance, which is a requirement for filtering, things would
be complicated and probably less efficient. Perhaps someone more into
dbus might provide better insight here...

I guess that we want to do, is to encourage use of the device database
to be limited to only information (mount point) and configuration
(volume slider, nautilus window position) data, not things like CPU
temperature which is updated many times a second. 

Applications needing streaming data should use existing libraries that
optionally are libhal aware, for painless device selection by the
application.

> On the other hand if we wish to do some sort of 'network' transparency
> in the future for this.  Say you'd list all the devices available to you
> on the network.  So in the future you'd have the teapot and the toaster
> devices and such, and your home network goes down and up because of a
> power failure or something you'd get all these toasters being removed and
> added.

Not at all on crack. A more contemporary example might be a big terminal
server and many X terminals which may have peripheral hardware and (USB)
ports.

> In this case however, the net traffic will be far greater bottleneck.
> 

I'm not sure it would really be a bottleneck if we just have a way of
limiting the usage to few events... But I haven't given this much
thought really.

Cheers,
David