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

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

James,

> Yeah, I think having an explicit value is best. I think it makes it
> easier to handle for the consumer of the API.

Sounds good.

> > 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.
>
> Out of curiosity do you need these properties purely for displaying to
> the user? If so I wonder if they shoud go on a new interface, e.g.
> DeviceProvisioningDiagnostics.
>
> We have a similar concept with AccessPointDiagnostics and
> StationDiagnostics. These interfaces hold extra information that isn't
> really needed to use IWD generally, but more debugging or displaying
> information in a UI. These seem to fit more into that category than
> needed for DPP in general.

The uses that I have in mind are:
1) Notify the user when a device is being configured (by monitoring
   State)
2) Determine whether to show the user a "Start" button or a "Stop"
   button.
3) Display a QR code and a label showing the user whether credentials
   are being given or received.

The benefit of properties over method return values for (2) and (3) is
that the front-end app gets to be stateless, so that the user could quit
and re-start the app and still see the QR code.

Thanks, and let me know what your thoughts are.

Sincerely,
Jesse