- 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