Should WebDriver BiDi extends WebDriver classic?

[sadym-chromium]

According to BiDi spec:

This specification extends WebDriver.

Which implies each WebDriver BiDi implementation implements WebDriver classic as well. The question is: should it be so?

Option 1 (current approach):
Assume any WebDriver BiDi server implements WebDriver classic.

• Pros:
  • BiDi can be implemented and tested incrementally on top of WebDriver classic.
  • Supports backward compatibility.
• Cons:
  • Each new WebDriver BiDi server implementation has to implement the WebDriver classic.

Option 2:
There can be WebDriver BiDi-only servers.

• Pros:
  • WebDriver BiDi can be implemented without need in implementing WebDriver classic.
  • Provides more flexibility, as does not require, but allows to have WebDriver classic implemented as well.
  • Supports scenario of migrating testing frameworks using CDP to WebDriver BiDi with minimal effort.
• Cons:
  • Migrating clients from classic to BiDi would require both classic + BiDi implementations.

[foolip]

I think option 2 is the current reality after #99 and we should reword the introduction of the spec. Maybe "supplements"?

[shs96c]

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.

[shs96c]

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 :)

[sadym-chromium]

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.

[sadym-chromium]

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?

1. WPT can use WebDriver Classic for preparation BiDi tests.
2. ... anything else?

[jgraham]

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.