[patch] wireless patch, take 2

[Sean Middleditch]

On Thu, 2004-05-27 at 15:22, Robert Love wrote:
> 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).

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.

What would be a better solution, perhaps, is to offer not only normal
properties but also pseudo, write-only properties.  One might just call
these methods.  Write a value out to these, a script/call-back is
invoked by HAL, and *if* that callout changes the property at the source
(the network settings) then you see the change in the corresponding
read-only HAL propert(y|ies).

HAL could even provide some extended signals/events, as well, such as
"failure to change ESSID" which could be used in several places, be it
the app that initiated the change or a tool like a network monitor which
might show all the recent actions on the interface and their state.  The
example signal could include the reason why the change failed, such
"callout does not exist" (i.e. administrator error), "operation not
supported", etc.  

> 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.

"Methods" don't really have to be *that* complicated.  I do think that
just a "set" interface won't work if it immediately changes a value
without the actual system using that change.  Aside from the "they'll
get permanently/long-term out of sync" issues, there's also the short
time-frame race issues.  Simply allowing some properties to be
write-only or making properties have a "delayed" set (you set the value,
but the read-version doesn't change until the HAL backend says it does)
woudl work, I believe.

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


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