Open sadym-chromium opened 2 years ago
I think option 2 is the current reality after https://github.com/w3c/webdriver-bidi/pull/99 and we should reword the introduction of the spec. Maybe "supplements"?
I'm not sure I agree that option 2 is the current reality: all the places I'm aware of that are implementing WebDriver Bidi already have existing WebDriver implementations.
In addition, although it would be lovely to have a wealth of browsers out there, each implementing WebDriver support, I'm not sure we'll see many entirely new browsers appearing, and those representing the bulk of the browser market already support the original WebDriver spec. Are people starting their WebDriver Bidi efforts from scratch, without extending (for example) the existing chromedriver
?
From a user-facing perspective, a single driver binary that implements both protocols is strongly preferable. Users already find it hard to manage keeping the driver executable and browser versions in sync, and adding another binary into the mix is distinctly suboptimal and will present a barrier to adoption.
I'm not sure how having WebDriver Classic support in the driver executable precludes "Supports scenario of migrating testing frameworks using CDP to WebDriver BiDi with minimal effort." since those frameworks that wish to do this need only use WebDriver Bidi directly without falling back to the WebDriver Classic.
We've spoken in meetings about eventually reformulating the original WebDriver spec on top of WebDriver Bidi. The two specs are going to be closely entwined with one another from that perspective. I'm not sure that's an argument for option 1 or 2 :)
Are people starting their WebDriver Bidi efforts from scratch, without extending (for example) the existing
chromedriver
?
That's exactly the case for now. Our implementation of WebDriver BiDi doesn't use ChromeDriver. Eventually it will be added to the ChromeDriver, but not yet.
From a user-facing perspective, a single driver binary that implements both protocols is strongly preferable. Users already find it hard to manage keeping the driver executable and browser versions in sync, and adding another binary into the mix is distinctly suboptimal and will present a barrier to adoption.
The suggestion is not to prohibit implementing both protocols in one server, but to allow implementing only one.
I'm not sure how having WebDriver Classic support in the driver executable precludes "Supports scenario of migrating testing frameworks using CDP to WebDriver BiDi with minimal effort." since those frameworks that wish to do this need only use WebDriver Bidi directly without falling back to the WebDriver Classic.
I meant, we don't need WebDriver Classic
for such clients, and having only WebDriver BiDi
is already sufficient.
It looks like the restriction is artificial, and BiDi by itself is self-sufficient. E.g. CDP clients doesn't require WebDriver Classic
at all. Are there any benefits of requiring each WebDriver BiDi
server to implement WebDriver Classic
?
WebDriver Classic
for preparation BiDi tests.I don't think it's worthwhile to spend too much time language lawyering here; the text in question is non-normative and anyway, there's no mechanism to enforce any text that suggests a BiDi implementation must also support WebDriver classic. So the upper bound on the effort we should put in to debating this should be based on an estimate of how much time would be saved by not having further discussions on this subject in the future :)
That said, I don't expect that BiDi implementation will always support WebDriver classic in practice e.g. Firefox will support BiDi without requiring a seperate driver binary, but normal WebDriver will still require geckodriver. Therefore I'm very happy to take a PR that changes any normative wording to make it clear it's fine to not support HTTP-based WebDriver, and softens the introductory text to make it clear it's an extension in the sense that we're reusing concepts and approaches from WebDriver, not that it's a strict implementation-level dependency.
According to BiDi spec:
Which implies each
WebDriver BiDi
implementation implementsWebDriver classic
as well. The question is: should it be so?Option 1 (current approach): Assume any
WebDriver BiDi
server implementsWebDriver classic
.WebDriver classic
.WebDriver BiDi
server implementation has to implement theWebDriver classic
.Option 2: There can be
WebDriver BiDi
-only servers.WebDriver BiDi
can be implemented without need in implementingWebDriver classic
.WebDriver classic
implemented as well.WebDriver BiDi
with minimal effort.classic
toBiDi
would require bothclassic
+BiDi
implementations.