[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: DCOP D-BUS HAL and new cd's
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2004-09-19 14:17:39
Message-ID: 200409191617.39910.hausmann () kde ! org
[Download RAW message or body]

On Sunday 19 September 2004 15:28, Kévin Ottens wrote:
> Le Samedi 18 Septembre 2004 19:39, Simon Hausmann a écrit :
> > Which part of hal gave you that impression?
>
> The simplified answer is using sloccount.
>
> hald : 14565 lines of C
> hald/linux : 10151 lines of C
>
> So, we have several solutions here:
> 1) HAL architecture doesn't help you to develop the os specific layer...
> then it's a lot of work to port it to something else
> 2) Linux is not helpful and then requires a lot of code to handle it
> correctly... then maybe for other OSes it'll be easier

3) Lines of code is a terrible metric on the quality, complexity and 
portability of software :)

Seriously, to me that is comparing apples with oranges. The linux portion is 
about extracting information from the kernel (into the udi hierarchy and 
name/value property sets) and the rest is about dynamically publishing that 
information over the system wide dbus. Two different solutions for different 
problems.

I find the interface between those two much more interesting. 
http://freedesktop.org/pipermail/hal/2004-June/000421.html describes a bit of 
it.

> Of course both of this statements are not sure... That's why in my humble
> opinion we'll be able to have a clear opinion on HAL when it'll be ported
> to something else than Linux.

You might find this thread interesting:

	http://freedesktop.org/pipermail/hal/2004-June/thread.html#416

As GNOME is using it in their volume manager in the latest release 2.8 I'm 
optimistic that it'll end up on more platforms soon.

On the client side you don't even necessarily need to use libhal. Instead just 
using dbus should work as well, as libhal is just a convenience wrapper. And 
as Harald has shown dbus can nicely be combined with a Qtesque API, without 
pulling any dependencies beyond libdbus.

Simon

[prev in list] [next in list] [prev in thread] [next in thread]