Problem with BSS properties

[Witold Sowa]

Dan Williams pisze:
> On Fri, 2009-12-25 at 03:37 -0800, Marcel Holtmann wrote:
>> Hi guys,
>>
>> so I am heavily toying with the new D-Bus API right now and I found some
>> weird behavior with within the BSS interface. So basically every BSS
>> object contains one property with the name "Properties". That is just
>> stupid and I hope it is just a bug.
>>
>> We should actually put the BSS properties as real properties of the BSS
>> interface. Then the PropertiesChanged signal could be doing something
>> meaningful and actually indicate signal strength changes etc.
> 
> I think that's what the spec from last summer originally had actually;
> maybe the implementation just got mixed up.  I see that I perhaps didn't
> make the spec completely clear:
> 
> O: /fi/w1.wpa_supplicant1/Interfaces/<interface_number>/BSSs/<BSSID>
> I: fi.w1.wpa_supplicant1.Interface.BSS
> 
> P: <BSS properties - identical to old API BSSID properties> (read-only)
> 
> 
> But yeah, each BSSID property should just be exposed as a property of
> the object instead of a "Properties" property as a dict as you say.
> 
I misunderstood the spec and I agree that it doesn't make a lot of
sense. I'll fix it soon. New issue appears now. When new scan results
arrive we will need to have both the new and the previous results in
order to compare properties (like signal level) and send appropriate
PropertyChanged signals. The problem is that Jouni doesn't like having
both the old and the new scan results at the same time because of risk
of excessive memory usage. So we have three options now:
1) Don't send PropertyChanged signals when BSS properties changes.
2) Keep both the new and the previous results  (and use memory for both)
and compare all BSS properties.
3) Keep only these BSS properties which really can change (level and
quality. anything else?).
I think that we can turn down the first one.

Regards,
Witek.