Thanks for filing this! cc @web-platform-tests/wpt-core-team

The main things we will need here are to bring a websocket client library into WPT, and to extend the client in tools/webdriver/ to be able to talk to BiDi as well. This will likely ultimately require an RFC, but we should have a good idea in mind of our plan before we file that :)

For a websocket client library, here are a few random choices I pulled from the internet:

• https://github.com/websocket-client/websocket-client (used in the internal Chromium tests for BiDi) - Py2/Py3 compatible.
• https://github.com/aaugustin/websockets/ - Py3 only, as it uses asyncio
• https://github.com/Lawouach/WebSocket-for-Python - appears to be on hiatus

Big choice seems to be - would asyncio be desirable? If so, we would have to design the extension to tools/webdriver such that it was loaded in python3-only, which might complicate things.

Making a decision here definitely requires an RFC about any new dependency and about the proposed API surface.

On the library question, I would take the position that we can accept Py3-only dependencies at this time. I think given the relevant timescales and the fact that vendors can already support both Py2 and Py3 we should choose the library we want rather than the one that happens to work with Python 2.

I think designing the interaction with the existing WebDriver client is not going to be terribly problematic either way; the entrypoint to bidi is pretty clearly defined so it's not like lots of the exisiting code will be affected. There will just be some mechanism to get a bidi connection from a session.

@k7z45 - do you have the time to own doing some experimentation with some of the websocket libraries above in WPT, to see what a client might look like? In particular it seems like deciding whether the asyncio-using library is fundamentally better or not would be most useful.

I'm happy to support you from the WPT side with getting setup, consulting on any problems you have with our infrastructure, etc.

In particular it seems like deciding whether the asyncio-using library is fundamentally better or not would be most useful.

I think myself and @jgraham are strongly in favour of a library using asyncio, FWIW.

@stephenmcgruer
Sure, I can try out the websocket libraries above.

1. I can try following their documentation to create examples for connecting, sending and receiving messages.
2. I can try to create an example that does use asyncio when asyncio is supported.
3. I can try to create an example that does NOT use asyncio even when asyncio is supported.

I think these examples will be standalone(outside of WPT).
What do you think?

Right now we have pywebsocket3 as a websocket server in wpt. Is there a desire to replace pywebsocket3?

@k7z45 - I think the more useful thing would be to try them within WPT, basically building a prototype for the RFC to point at. Given the multiple requests for using asyncio, I would suggest taking https://github.com/aaugustin/websockets/ and adding support for it to tools/webdriver/ . Does that make sense? I'm happy to sync offline about a plan here :).

Right now we have pywebsocket3 as a websocket server in wpt. Is there a desire to replace pywebsocket3?

@zcorpan - At the moment, I consider that out of scope. If we used something like https://github.com/aaugustin/websockets/ we could build our own websocket server on top of it (i.e. integrate it into wptserve), but that would have to wait until Q2 2021 (py3-only timeline).

Got it, will sync with you.
cc @JohnChen0