new dbus api coalesces state change

[Sam Leffler]

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.shmoo.com/pipermail/hostap/attachments/20100819/8c318d37/attachment.htm