jgraham
commented
4 years ago So I see two key issues here:
- What state, if any, is attached to a specific connection, vs a specific session (consider: the list of enabled events). If we have state on the connection then dropping and reopening the connection will obviously lose that state, whereas the session can persist the state.
- What can a client usefully do if the connection drops. Presumably in this case it's going to lose any events that would have been emitted in that time, unless we require implementations to provide some kind of event buffer. But if we do the buffer can't have an infinite size, so there is some possibility of event loss. If we allow a client to reconect, how can it synchonise itself with the current state of the world? For devtools type use cases this seems relatively unproblematic since the interaction is either passive or at least human-mediated (it's unsurprising to a human if a devtools connection dropping means we miss some netowrk events, say). But for automation, a script waiting on an event that never comes is probably just going to hang.
So, unless there's some clever solution here, I think we have a few choices:
- Build the spec in such a way that events may be buffered so that we can allow some reconnection without interruption. In this case events may be dropped and if the client can't handle that it can choose to just drop the session. We could have some messge on connect indicating whether any events were dropped, so the client could make some appropriate decision about how to proceed.
- Allow reconnection without providing any buffer. That means clients are almost guaranteed to miss events, so this mode doesn't seem useful for driving automation, but it could be useful for scenarios where WD1 controls the automation and BiDi is just used for data collection.
- Simplify the spec by not supporting reconnection within a single session, on the basis that the implementation complexity isn't worth it for the number of use cases it solves.
This was asked by @AutomatedTester in https://github.com/w3c/webdriver-bidi/pull/24#discussion_r434583966.
The minimum we should do is to define clearly what happens to the remote end if the connection is reset. Beyond that, it would be good if it's possible for a client to reconnect, and the most likely way that wouldn't be possible is if we decided (for simplicity elsewhere) that there could only be one websocket connection at all for the duration of a session. In other words, this issue is likely slightly entangled with what to do if a client tries to set up two parallel connection.