saresend
Interoperability with existing Selenium solutions
The Selenium project knows different implementations in different languages (Python, Go, Java, ...) of the webdriver, a W3C recommendation. In this issue I will cover Selenium 2.0 (based on Selenium 1.0 + webdriver).
WebDriver is a remote control interface that enables introspection and control of user agents. It provides a platform- and language-neutral wire protocol as a way for out-of-process programs to remotely instruct the behavior of web browsers.
Selenium is composed of :
- A driver to drive the corresponding browser.
- A client with a webdriver implementation to drive the browser through commands. These commands are send to the driver.
- A server which allows to drive a remote browser
We are currently looking for a first version where users do not need to be worried about the server side and the driver (chrome driver, gecko driver, IE driver, ...) to choose. The issue #12 comes with a discussion around that and the possibility to provide a way to configure a remote server.
If we want to provide a crate compatible with existing Selenium solutions we should allow the user to specify a remote Selenium server. It can be a Selenium grid composed of a hub connected to Selenium nodes (ex : a project with Docker images), or a standalone version composed of a server and a driver.
Companies have their own solutions or use those of service companies like BrowserStack / SauceLabs... which provide a remote URL. If we want users to adopt this crate, we need to keep that in mind.
