[patch] wireless patch, take 2

[Robert Love]

On Thu, 2004-05-27 at 22:40 +0200, David Zeuthen wrote:

> Nice catch, you're right, I didn't think of that, sorry. 

Only because I am one of those people who hard code my ESSID, I
guess ;-)

But the thinking comes from the way we do stuff in the kernel, too: if
HAL is the be-all end-all for device access, it must enforce *zero*
policy because we never know (and we don't want to influence/dictate)
what sort of code is built on top.

> The thing is that I do think the HAL should offer some kind of
> manipulation of the hardware, hence the API suggestion. It seems like a
> nice way to offer this through setting properties but I'm not completely
> sure how it would work. Hence, why I'd like to see some discussion of
> the wireless network usecase which may be one of the more complicated
> ones.

Yah.  One thing about providing richer API's: they could always be
provided by HAL-based libraries that sit on top of HAL and wrap and
extend its functionalities.  See the libinput library I posted earlier
to utopia-list.

So HAL could stay minimal around the basic key/value set/get idea.

> Remember, for reading information we also have what I've called
> conditions that complement properties, e.g. a HalDevice can emit a
> DeviceCondition. This is used for things that not easily expressible in
> properties such as "this volume was unmounted" (implemented) or
> "processor is overheating" (not yet implemented).

Or overeating :)

> It seems whether we use properties or an org.freedesktop.Hal.Device like
> API to manipulate a device is largely implementation detail to me, but
> the latter approach does offer a lot more flexibility.

I do agree that using a richer API gives us more flexibility, especially
to do access controls, which may well be very important.

	Robert Love



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