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
The front-end applications using the Agent, for example the Cloud Editor, have no way to be notified when a new board is connected (or in general when there are "port changes"). So the way it's done now is by polling: sending a LIST command every N seconds.
This is both inefficient (a lot of useless LIST commands) and slow (the user has to wait up to N seconds before they see the board they have just connected). It would be nice if the front-end could receive a notification when a new board is connected, without polling.
Describe the request
New commands:
startwatchports: starts watching and returns multiple add events (corresponding to all the known ports at that time)
stopwatchports
When the WebSocket connection is closed by the client, the agent will automatically stop sending events and eventually stop watching for port changes (this is an internal implementation detail).
At the start of the communication, the watch functionality is stopped, and has to be started manually with a startwatchports.
If the agent is already sending watchport events, a startwatchports will not do anything. Same for the other way around with stopwatchports.
Current problem
The front-end applications using the Agent, for example the Cloud Editor, have no way to be notified when a new board is connected (or in general when there are "port changes"). So the way it's done now is by polling: sending a
LIST
command every N seconds.This is both inefficient (a lot of useless
LIST
commands) and slow (the user has to wait up to N seconds before they see the board they have just connected). It would be nice if the front-end could receive a notification when a new board is connected, without polling.Describe the request
New commands:
startwatchports
: starts watching and returns multiple add events (corresponding to all the known ports at that time)stopwatchports
When the WebSocket connection is closed by the client, the agent will automatically stop sending events and eventually stop watching for port changes (this is an internal implementation detail).
At the start of the communication, the watch functionality is stopped, and has to be started manually with a
startwatchports
.If the agent is already sending watchport events, a
startwatchports
will not do anything. Same for the other way around withstopwatchports
.Result message:
Note: multiple port additions or removals would be sent using multiple
watchportevent
messages.Describe the current behavior
Currently the Agent does not support watch functionality.
The text was updated successfully, but these errors were encountered: