Issues with new D-Bus API

[Marcel Holtmann]

Hi Witold,

> > so I have been hacking on a client using the new D-Bus API and found a
> > couple of things that are sort of weird and could be done way simpler.
> > Some of them seems just copied from the old API and I think it is time
> > to fix this now before we actual get real users of this API.
> > 
> > 1) DebugParams parameter as a struct is too complex
> > 
> 
> I have new bunch of patches on my GIT: git://repo.or.cz/hostap-gosc2009.git
> 
> One of the patches fixes a bug in DebugLevel setter value type, but it's
> irrelevant now since Marcel's patch changes DebugLevel to string (and
> that's fine for me).

sorry about that. Wasn't sure if you were working on it. And the debug
level numbers confused the hell out of me.

Jouni, how do you wanna merge this? Cherry pick the patches?

> > 7) Change of BSS properties
> > 
> 
> I have added a properties change notifications to BSS objects and I
> modified code related to PropertiesChanged signal. Till now, every
> PropertiesChanged signal contained only one property. Now, we don't send
> PropertiesChanged signal explicitly but rather mark property as changed
> and then send a signal containing all properties marked as changed in
> the object. Signal is actually being sent in three cases as described in
> commit message. Changed in properties which are not caused by any DBus
> call may be signalized with slight delay (currently up to 5ms) unless we
> call wpa_dbus_flush_object_changed_properties() or
> wpa_dbus_flush_all_changed_properties() before. Delay is caused by the
> timer which makes it possible to wait for other changed properties to be
> marked and included into signal. We need to consider which properties
> change notification delay is acceptable and which is not and add
> appropriate flushing calls after marking properties changed.

Sounds good to me. We can figure out details about important properties
later. Not sure that it really matters.

> > Is anybody really using "MaxRate" property. Wouldn't it better to export
> > "Rates" as array of uint16? And if it is sorted the client could easily
> > extract the max rate from there.
> 
> Done, but there is an array of uint32 since we expose rates in b/s.
> uint16 would be too small even if we would expose it in kb/s since
> 2^16=64000 what is much less than 802.11n rates. The array is sorted
> decreasing so the maximal rate is the first rate in the array.
> This also fixes a bug with MaxRate. Exposed value was given as
> multiplicity of 500000b/s, i.e. as it is stored in IE.

Using an uint32 is fine. Only the stupid usage of signed integers was
pretty much pointless.

Regards

Marcel