Interoperability with existing Selenium solutions

[theredfish]

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.

Source

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.

[Rajagopalan-M]

@theredfish

Such an excellent summary.