search

WebThingsIO / thing-url-adapter

Proxy adapter for Web Thing API endpoints
Mozilla Public License 2.0
22 stars 18 forks source link

Prevent setting a property to its current value from hanging. #83

Closed mrstegeman closed 4 years ago

benfrancis commented 4 years ago

One other thought - is the issue here that the adapter is trying to proxy a request/response style REST API to a pub/sub style WebSocket API? Usually a propertyStatus message wouldn't be sent if the value of the property doesn't change. Rather than defaulting to always using a WebSocket where available, another approach would be to always proxy HTTP requests to HTTP requests and always Proxy WebSocket messages to WebSocket messages. That way there shouldn't be mismatches in expected responses.

mrstegeman commented 4 years ago

I'm assuming that if no WebSocket URL is detected it successfully falls back to a PUT request and that succeeds in setting the same value. (I don't have a native web thing with properties handy to test with).

Yes, the path taken for that case does the right thing and sets the property value as soon as the HTTP response comes back.

mrstegeman commented 4 years ago

One other thought - is the issue here that the adapter is trying to proxy a request/response style REST API to a pub/sub style WebSocket API? Usually a propertyStatus message wouldn't be sent if the value of the property doesn't change. Rather than defaulting to always using a WebSocket where available, another approach would be to always proxy HTTP requests to HTTP requests and always Proxy WebSocket messages to WebSocket messages. That way there shouldn't be mismatches in expected responses.

Yes, that's essentially what is happening. The WebSocket is the faster path here, so it makes sense to use it. The spec is where things differ, though. These are both calling the same thing internally on the web thing, to set the property value, which in itself is a request. However, the WebSocket doesn't have a mandatory reply to that.