[PATCH 0/2] dbus: Do Not Coalesce State Changed Signals

[Jouni Malinen]

On Mon, Oct 24, 2011 at 10:05:04AM -0500, Dan Williams wrote:
> I used to have a problem with this, but I now see where it makes sense
> for the State property alone.  Most properties *should* be coalesced to
> reduce dbus traffic, but the State property should probably just trigger
> an immediate emit of the interface's changed properties.  State doesn't
> change that often so it wouldn't meaningfully increase D-Bus traffic.

What exactly are these state changes used for? The main problem I see
with this is that wpa_s->wpa_state is supposed to be internal data for
wpa_supplicant and the values it has and the way they are used are
subject to change whenever needed.. As such, I would really not want any
external functional to depends on that for anything beyond maybe showing
some debug information.

There are already some horrible hacks in place for wpa_state (just see
how WPA_IDLE is generated in Android builds) and I really do not want to
have to consider supporting something like that with the D-Bus
interface.

If there is desire to actually use this type of information for taking
some actions, it would be much safer to define a new value that will be
generated based on internal state (including wpa_s->wpa_state) and
define that in a way that makes it easier to maintain this in a stable
way even if the internal implementation changes.

-- 
Jouni Malinen                                            PGP id EFC895FA