[patch] wireless patch, take 2

[Sean Middleditch]

On Thu, 2004-05-27 at 15:44, David Zeuthen wrote:
> On Thu, 2004-05-27 at 15:41 -0400, Robert Love wrote:
> > On Thu, 2004-05-27 at 15:36 -0400, Sean Middleditch wrote:
> > 
> > > As you pointed out before, just setting a property is a little icky; you
> > > can set a value and not have it actually mean anything.
> > 
> > Well, I pointed that out before in response to having HAL use callouts
> > to set the properties (e.g., we don't actually change much from today).
> > 
> > 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.
> >
> > So there is no disconnect between HAL and reality.
> > 
> 
> 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?
> 
> What about volume.label, should we physically write to the partition
> when the user sets this properties?
> 
> 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?
> 
> How many of our exported properties does this impact? Not a lot I
> guess..

This is, honestly, I think a better case for pseudo/write-only
properties.  Write out a chunk of network options to network.reconnect,
for example, and the backend code and/or callout does its thing.  Iff
those are successful then all of the relevant properties are updated in
concert.  Transaction support is just getting a little over-board, I
think; the ratio of code necessary to do something like that versus
write-only properties is pretty is pretty high.

Alternatively, instead of transaction support, atomic multi-value
operations would might be an idea.  Many successive reads of
inter-dependent properties could result in contradicting data if the
values change during the middle of those read requests.  With atomic
multi-value sets you could have the backend/callback notified once when
they all change together, and then operate away.  Apps that need to only
change one or several of a group of inter-dependent values would only
need to do the set operation on the values that actually changed.

I would also argue that during the transition the properties should
retain whichever value makes the most sense for the actual operating
conditions.  I.e., if the backend/callout has to shutdown the current
network connection to attempt reconnecting to a different network, those
properties should be immediately updated to the proper unconnected
values.  An app that happens to make a query during that transition
should not be lied to, ever.

> 
> Regards,
> David
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.


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