search

w3c / wot-profile

Web of Things (WoT) Profile
http://w3c.github.io/wot-profile/
Other
16 stars 8 forks source link

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

Closed benfrancis closed 1 month ago

benfrancis commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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.