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

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

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?

> > +               string Role [readonly, optional]
> > +
> > +                       Reflects the DPP role. Possible values are
> > "enrollee"
> > +                       and "configurator"
>
> I don't think you actually need this one. The role should be implied by
> however you started DPP:
>
> StartEnrollee() -> enrollee
> StartConfigurator() -> configurator
> ConfigureEnrollee() -> configurator

One use case that I'm trying to address is when a user launches the
front-end app while DPP is already active. There are two ways that I can
think of to handle this:

1) The front-end stops and re-starts DPP if the user requests it. This
only requires iwd to provide State, so that the front-end can see if a
previous invocation must be stopped.

2) iwd provides sufficient information via properties to restore the
previous invocation: State, Role, and URI.

I originally had option 2 in mind, but if DPP invocations are intended
to be transient, then perhaps option 1 would be more appropriate. Let me
know what your thoughts are, and I'll send a revised patch.

Thanks.

Sincerely,
Jesse