new dbus api coalesces state change

[Dan Williams]

On Thu, 2010-08-19 at 18:41 -0700, Sam Leffler wrote:
> On Thu, Aug 19, 2010 at 6:10 PM, Witold Sowa <witold.sowa at gmail.com>
> wrote:
>         Sam Leffler pisze:
>         
>         > The coalescing of PropertiesChanged signals is great but
>         doing this
>         > for State's means the client has to infer missing states.
>         >  Unfortunately the way things are implemented it's not
>         simple to just
>         > flush a pending signal in the lowest level of the dbus code
>         where it's
>         > easy to recognize this as the state has already been
>         changed.  Any
>         > suggestions on how to handle this?  Or is it expected the
>         client will
>         > just infer all the missing state transitions? (can be hard
>         and lead to
>         > problems)
>         >
>         > -Sam
>         >
>         
>         Hi Sam,
>         
>         You may look at wpa_dbus_flush_object_changed_properties
>         function in
>         dbus_new_helpers.c. A pending PropertiesChanged signal will be
>         sent
>         immediately when this function is called. We might add it to
>         wpas_notify_state_changed in notify.c so PropertyChanged will
>         be sent
>         immediately every time state changes. Or actually, we could
>         put it into
>         some new function in dbus_new.c like
>         wpas_dbus_signal_state_changed and
>         call if from wpas_notify_state_changed.
>         
> 
> 
> Is State always the last property changed when multiple will be
> coalesced?  I don't think so; in particular CurrentBSS seems to follow
> and I've already had to deal w/ handling that out of order on the
> client side (e.g. so the state change is applied to the new bss and
> not the previous).

Yeah, I can see how that would be an issue; but it's somewhat more
complicated than just moving CurrentBSS before State.  When you
disconnect CurrentBSS should flip to nothing; so you still would need to
cache whatever the old BSS is and then apply the disconnected state to
the cached one?

The code appears to usually have the pattern of updating the state
before updating the CurrentBSS, except for "associate" paths.  So the
D-Bus interface should be following the same patterns as the control
interface, except for the coalescing.  So maybe we fastpath State,
CurrentBSS, and CurrentNetwork?

Dan

> This would be easy if the new state were passed down from above and
> the notify methods called before modifying the global state.  Then you
> could just check the properties changed flags and notice a new state
> value would overwrite an existing state and flush.
> 
> 
> I'm going to try and handle this on the client side but I believe the
> state change graph is ambiguous so it may not be possible to infer the
> missing states. Not sure if matters; will find out.
> 
> 
> -Sam
> 
> 
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap