[HTTP Basic Profile] Require that async actions set the synchronous member of an ActionAffordance to false

[benfrancis]

Currently the HTTP Basic Profile says:

If the synchronous member of the ActionAffordance [wot-thing-description11] is undefined then the Web Thing MAY respond with either a Synchronous Action Response or Asynchronous Action Response.

This might cause a generic WoT Consumer which doesn't implement the profile to get confused if it invokes an action, expects a synchronous response containing the action output, but actually gets an asychronous response with an ActionStatus payload linking to a dynamic resource.

We could consider asserting that if a Thing implements an asynchronous action then it must set the synchronous member of the ActionAffordance to false, to be more explicit that it will not respond synchronously.

This should then be enough to tell a generic Consumer not to expect the action output in the response to the invokeaction request, even if it can't then consume the queryaction and cancelaction operations.

Currently it's technically possible that the same action affordance to respond either synchronously or asynchronously depending on the anticipated duration of the action, and for a sufficiently sophisticated Consumer to understand both responses. This change would remove that flexibility in favour of more predictable behaviour, and a "progressive enhancement" approach. Consumers which don't support asynchronous actions can either "fire and forget" an action invocation, or ignore an asynchronous ActionAffordance altogether.

[egekorkan]

Currently it's technically possible that the same action affordance to respond either synchronously or asynchronously depending on the anticipated duration of the action, and for a sufficiently sophisticated Consumer to understand both responses

Doesn't this contradict the goal of simplifying WoT development. That is quite a complex behavior.

I think it would be just much simpler if profile mandates defining the synchronous keyword.

[benfrancis]

I think it would be just much simpler if profile mandates defining the synchronous keyword.

I agree.

It's a shame that the synchronous member doesn't have a default value in the Thing Description specification, but maybe that wouldn't make sense for all protocols.

I think we were just following the Thing Description specification which says "Lack of this keyword means that no claim on the synchronicity of the action can be made." but on reflection this just makes things more difficult for Consumers.

[egekorkan]

It's a shame that the synchronous member doesn't have a default value in the Thing Description specification

The reason for that was that both ways are a claim. The other keys with defaults have a default since the default is the "safer" way.

this just makes things more difficult for Consumers.

This is indeed the case and a TD producer should have a value for this. If needed, this can be made more assertive in TD 2.0. Making it mandatory would have invalidated all previous TDs.

[danielpeintner]

FYI: The TD1.0 spec does not have the term synchronous while TD1.1 does introduce it.

Not sure, but maybe the profile should make clear that it works on top of 1.1.
At the moment 1.0 and 1.1 are used interchangeably ... anyhow, I do not have a strong opinion. I just wanted to mention the fact.

[benfrancis]

@danielpeintner Ooh, good catch. The term profile doesn't exist in TD 1.0 either so it's technically not possible to use a profile with TD 1.0 at all. We should only be referencing TD 1.1, but I see we are still referencing TD 1.0 in many places.

I have filed #410.