You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some talks we have agreed on the benefits of using websockets instead of HttpRequests as transport for ubus calls. While being more performant for many small calls, it will enable the possibility to use UBUS subscriptions and server-push notifications. ( Some background on #42)
As this requires as a precondition to add websocktes support to uHttpd, we are leaving this issue open till that moment, to track any related discussion.
In the meantime, the approach in Luci-ng will be to implement a Ubus service as an abstraction layer, so when later changing transport it is mostly transparent for the rest of the application, and only new possibilities should be build.
The text was updated successfully, but these errors were encountered:
In some talks we have agreed on the benefits of using websockets instead of HttpRequests as transport for ubus calls. While being more performant for many small calls, it will enable the possibility to use UBUS subscriptions and server-push notifications. ( Some background on #42)
As this requires as a precondition to add websocktes support to uHttpd, we are leaving this issue open till that moment, to track any related discussion.
In the meantime, the approach in Luci-ng will be to implement a Ubus service as an abstraction layer, so when later changing transport it is mostly transparent for the rest of the application, and only new possibilities should be build.
The text was updated successfully, but these errors were encountered: