[patch] wireless patch, take 2

[Robert Love]

On Thu, 2004-05-27 at 20:24 +0200, Kay Sievers wrote:

> After following the discussion about the inclusion of the wirleless
> configuration inside of HAL, I'm wondering about the border of features
> to be included in HAL? Should it be able to eject my CD or set the
> volume of my soundcard too? What is the long term goal here?

Defining the exact scope of HAL is something that has always troubled
me.

I think we all agree to a few things that HAL ought to do:

	- Device discovery, enumeration, so on
	- No policy

I also think we all agree that HAL should display some basic inherent
properties associated with the enumeration of the devices.  Maybe even a
lot of properties associated with the devices.

The question today lies in where do we stop with the properties we
offer, and, do we allow setting a property to trigger a side effect of
actually going out and enforcing the property change onto the device
(e.g., doing a set on the essid property actually changes it on the
hardware).

Cons to allowing HAL to set these properties are complexity,
overstepping of scope, and so on.

Pros are functionality, completeness, etc.

I wasn't totally for having HAL do things like actually set the wireless
device's ESSID or adjust your soundcard's volume, but discussion with
Joe has persuaded me to lean in the other direction.

The biggest reason: libraries and applications that use HAL can utilize
libhal to _get_ properties, but then must go out and _set_ them via some
other method.  That is just dumb.  Either HAL provides a solution, or it
does not.  We should not force apps to use two code paths or understand
two API's (HAL and the device's).

Imagine a wireless applet.  It gets wireless information from HAL.  But
to set it, it has to deal with iwlib.  So why use HAL at all?  The
conclusion, to me at least, is that HAL needs to provide (a reasonable
subset of) all properties and allow actual manipulation of these
properties.  Otherwise, it isn't complete.

This is a stretch for me.  20 minutes ago I was more of the minimal-
inherent-properties-only and no-setting-at-all camp.  Joe is very
persuasive when armed with a shank.

So, how do we allow setting?

Here is where I _am_ staunch.  I think we need to stick with our current
set/get interface.  That is, as sweet as having a method interface that
can utilize D-BUS access controls is, I feel we need to stick with the
simplicity and slickness of the current set/get thing.  If the property
cannot be abstracted as a key/value pair and controlled via set/get,
then it is outside the scope of HAL.

So there!

	Robert Love



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