Skip to content

Instantly share code, notes, and snippets.

@adamgoucher

adamgoucher/Browser 'shims' and Webdriver.md

Created November 21, 2012 16:58
Show Gist options
  • Save adamgoucher/4126033 to your computer and use it in GitHub Desktop.
Save adamgoucher/4126033 to your computer and use it in GitHub Desktop.
Download ZIP
Browser 'shims' and Webdriver
Raw
Browser 'shims' and Webdriver.md

  • The stated long-term goal for the WebDriver project is to be the reference implementation of the W3C browser automation standard from a client perspective

  • The browser vendors [w|s]ould provide 'shims' which know about the WebDriver JSON protocol

  • Google and Opera do already, Mozilla will shortly with Marionette

  • PhantomJS (non-vendor) is 'ready'

  • The Se project produces one for IE (which would be happily handed off to MS should they come to the table)

  • shims will likely come in two types; jar or executables (depending on platform)

  • WebDriver comes in two flavours; WebDriver and Remote WebDriver (see every other naming rant I've gone on...)

  • WebDriver integration of new browser into a binding involves wrapping the shim in that language and pumping the commands to it on whatever port it lit up on (see Opera with Python)

  • Remote WebDriver integration is possible through one of two ways [or both really...]

    • inclusion in the Java Client Bindings which means it is exposed via the Selenium Server distributed by the project and passing in the appropriate Desired Capabilities JSON blob to the server
      • even this might require starting the Selenium Server with a specific parameter (-Dwebdriver.chromedriver.server for instance)
      • or starting the shim server on the target listening on a known port (such as with Android)
    • start the server on the target and tell the Remote constructor where your command executor is and telling it about the shim (kinda like how Sauce OnDemand integrations work)

  • There is no real criterion on how/when a browser shim gets integrated into the Java Client Bindings other than friend-of-the-project submits a patch or someone with the commit bit wants it in there and does it

  • The Java /Client/ Bindings are involved since the Se Server delegates execution of things received via Remote WebDriver to WebDriver and since the server is java...

So ... from an external bindings that use Remote WebDriver perspective, to integrate new browsers/shims into a bindings they can

  • Twist in the wind
  • Wait for the Java Client to grow support for the browser
  • Add a new capability that knows about what port the shim is expected to be listening on and route commands to it
Raw
Browser shims and Webdriver.md

  • The stated long-term goal for the WebDriver project is to be the reference implementation of the W3C browser automation standard from a client perspective

  • The browser vendors [w|s]ould provide 'shims' which know about the WebDriver JSON protocol

  • Google and Opera do already, Mozilla will shortly with Marionette

  • PhantomJS (non-vendor) is 'ready'

  • The Se project produces one for IE (which would be happily handed off to MS should they come to the table)

  • shims will likely come in two types; jar or executables (depending on platform)

  • WebDriver comes in two flavours; WebDriver and Remote WebDriver (see every other naming rant I've gone on...)

  • WebDriver integration of new browser into a binding involves wrapping the shim in that language and pumping the commands to it on whatever port it lit up on (see Opera with Python)

  • Remote WebDriver integration is possible through one of two ways [or both really...]

    • inclusion in the Java Client Bindings which means it is exposed via the Selenium Server distributed by the project and passing in the appropriate Desired Capabilities JSON blob to the server
      • even this might require starting the Selenium Server with a specific parameter (-Dwebdriver.chromedriver.server for instance)
      • or starting the shim server on the target listening on a known port (such as with Android)
    • start the server on the target and tell the Remote constructor where your command executor is and telling it about the shim (kinda like how Sauce OnDemand integrations work)

  • There is no real criterion on how/when a browser shim gets integrated into the Java Client Bindings other than friend-of-the-project submits a patch or someone with the commit bit wants it in there and does it

  • The Java /Client/ Bindings are involved since the Se Server delegates execution of things received via Remote WebDriver to WebDriver and since the server is java...

So ... from an external bindings that use Remote WebDriver perspective, to integrate new browsers/shims into a bindings they can

  • Twist in the wind
  • Wait for the Java Client to grow support for the browser
  • Add a new capability that knows about what port the shim is expected to be listening on and route commands to it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment