- From: Ben Francis <ben@krellian.com>
- Date: Thu, 25 Apr 2024 19:42:26 +0100
- To: Luca Barbato <luca.barbato@luminem.it>
- Cc: public-wot-wg@w3.org
- Message-ID: <CAMpSprkUoSCZWJGZNFCYJJGCDJEOkzxO97dQ5qGKAdP4QO4C-A@mail.gmail.com>
On Thu, 25 Apr 2024 at 18:30, Luca Barbato <luca.barbato@luminem.it> wrote:
> That's the idea. I'm starting from the concern of people having TD
> consumers that would get very confused by profiles.
>
Is there any evidence this actually happens in practice, or is it just a
theoretical concern?
> If that's accepted we have to make it way more evident.
I agree this may not be obvious until you actually come to implement the
profile, or consume a Thing which conforms to it.
>
> adding a subprotocol to the invoke action form might solve the pressing
> problem since then the consumer would not present the async action.
>
If that's what it boils down to, what response would a generic Consumer
expect from an HTTP POST request to this action endpoint, that if they
didn't receive it would confuse them?
"actions": {
"fade": {
"title": "Fade",
"description": "Fade the lamp to a given level",
"synchronous": false,
"input": {
"type": "object",
"properties": {
"level": {
"title": "Brightness",
"type": "integer",
"minimum": 0,
"maximum": 100,
"unit": "percent"
},
"duration": {
"title": "Duration",
"type": "integer",
"minimum": 0,
"unit": "milliseconds"
}
}
},
"forms": [{"href":
"https://mywebthingserver.com/things/lamp/actions/fade"}]
}
}
Perhaps just making it mandatory to set the synchronous member to false for
asynchronous actions would actually solve the problem.
Received on Thursday, 25 April 2024 18:42:42 UTC