[patch] wireless patch, take 2

[Joe Shaw]

On Thu, 2004-05-27 at 21:44 +0200, David Zeuthen wrote:
> > Now I am suggesting that HAL actually have side effects to certain
> > properties and go out and set them on _its own_.
> > 
> > E.g., I do a hal_device_set_property() on a device's ESSID and then HAL
> > goes out and tries to change the ESSID.  The property is changed iff HAL
> > changes the property physically.

Presumably hal_device_set_property() would return an error if setting
the ESSID failed for some reason.  But at least it would be done in HAL
and not a callout.

> This is quite clever actually. And we'd still support the distro
> specific things when things actually change, because then the callout is
> fired, right?

Right.

> What about volume.label, should we physically write to the partition
> when the user sets this properties?

I don't think it's an unreasonable task, although I definitely have some
concerns about who/what should be allowed to do that.

> And some properties might need to be updated in concert, e.g. you want
> to change ESSID, Wireless mode and perhaps a few more at the same time.
> Should we support transactions from libhal?

I don't know for sure.  I think you can use the ioctl() to set the
things independently, although it's probably not all that useful.  I
think ideally apps would build on top of the HAL properties to do
something sane.

That said, though, it probably makes sense to be able to queue up
property sets.

> How many of our exported properties does this impact? Not a lot I
> guess..

Not many yet. ;)

I could see things like sound properties, maybe power management in
here.  I don't have as much of an opposition to setting IP address in
here as others do, etc.

Joe


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