Re: [PATCH 2/2] doc: Add State and Role properties to DPP API

[Denis Kenzior <denkenz@gmail.com>]

Hi Jesse,

On 6/23/22 14:07, Jesse Lentz wrote:
> Hi Denis,
> 
>> Inferring the state is fine if you can do this reliably.  One problem with
>> optional properties is that once they transition from 'defined' -> 'undefined'
>> there is no PropertiesChanged signal that is sent (or rather you have to look
>> into the invalidated_properties array of that signal).
>>
>> We have been designing our APIs with the assumption that many bindings wouldn't
>> be using this invalidated_properties reliably and added another point of reference.
>>
>> For example, Station.ConnectedNetwork is invalidated when Station.State goes
>> into the 'disconnected' state and thus not explicitly 'changed'.  But the DBus
>> client can infer that Station.ConnectedNetwork is 'undefined' at that point.
>>
>> But maybe bindings have improved over the years and we should just rely on
>> invalidated_properties being taken into account properly?  If so, that would be
>> a good argument to make 'State' optional.
> 
> Hmm, I wasn't aware of that. I can only comment on the GLib binding,
> which works reliably as far as I can tell - it supplies both changed and
> invalidated properties to the user-registered callback, which gets
> called in response to both changed and to invalidated properties.
> 

Ok, good to know that this works well.

> But if other bindings handle it incorrectly, then I suppose there's no
> compelling reason to make it an optional property.

Maybe I shouldn't blame the bindings as much as the documentation.  This wasn't 
a widely explained feature at the time we started, and this project is getting 
pretty old.

But yes, maybe it is easier to just make this property mandatory while all 
others can be made optional.

Regards,
-Denis