| 1 |
On Sunday 17 May 2009 14:15:31 pk wrote: |
| 2 |
> > But you have that in the current setup. Hal (for better or worse) is the |
| 3 |
> > daemon. dbus is simply a message transport and can be omitted from the |
| 4 |
> > conceptual diagram |
| 5 |
> |
| 6 |
> Why is dbus needed? Why can't the user space apps talk to the user space |
| 7 |
> daemon directly? To me it's just another unnecessary layer, each layer |
| 8 |
> needs some kind of translation and thus resources. To me hal or whatever |
| 9 |
> may replace it should have a minimalist approach. |
| 10 |
|
| 11 |
Because the methodology is not that user-space apps talk to hal, but that hal |
| 12 |
sends events to user space apps that are listening. And hal does not and |
| 13 |
should not know anything about those apps. |
| 14 |
|
| 15 |
Polling vs events is a problem that was solved a very long time ago. For a |
| 16 |
dynamically changing system, events wins hands down almost always (one major |
| 17 |
exception - real time OSes). It's asynchronous, easier to program and both hal |
| 18 |
and the user space app talk to one and only one well defined API, and just |
| 19 |
forget all about timing issues. |
| 20 |
|
| 21 |
From an engineering point of view, a message bus is an excellent idea. |
| 22 |
|
| 23 |
-- |
| 24 |
alan dot mckinnon at gmail dot com |
Archives