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

["Jesse Lentz" <jesse@twosheds.org>]

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.

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

Thanks.

Sincerely,
Jesse