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

[Denis Kenzior <denkenz@gmail.com>]

Hi Jesse,

On 6/23/22 11:30, Jesse Lentz wrote:
> Hi James,
> 
> Thanks for your feedback.
> 
>>> +Properties     string State [readonly, optional]
>>> +
>>> +                       Reflects the DPP state. Possible values are
>>> "presence",
>>> +                       "authenticating", and "configuring".
>>
>> I think a "stopped" state would also be needed.
> 
> As a user of the API, I can infer that DPP is inactive if "State" is
> undefined. A non-optional State property with an explicit "inactive"
> value should provide equivalent information; would you prefer the latter
> approach?

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.

Regards,
-Denis