W3C Python WebDriver local end

Hi all,

So I am working on the new Python local-end for use in the W3C tests, and I
have run into a general problem. There are places where the spec differs
from the current implementations in significant and breaking ways,
including the three following cases that will have wide-spread impact:
  1. In
https://dvcs.w3.org/hg/webdriver/raw-file/ac1cadc32661/webdriver-spec.html#json-encoding-of-commandsthe
spec specifies that a command should contain a JSON payload with three
fields, sessionId, name, and parameters, Selenium uses JSON payloads that
just consist of the value of the parameters field (the other two fields in
implicit in the end point of the command).
  2. In
https://dvcs.w3.org/hg/webdriver/raw-file/ac1cadc32661/webdriver-spec.html#status-codesthe
spec defines status codes as strings, but Selenium uses integers.
  3. The spec doesn't seem to provide for cases where responses to commands
don't include a JSON payload, but Selenium returns an empty body for some
commands on success (such as get and quit).

Ideally the Python local-end in use for the spec should conform exactly to
the specified behavior, but this does make developing, debugging, and using
it nearly impossible as there isn't currently a remote end that conforms to
the spec. My current thinking is that I should allow it to work in to
modes, 'strict' and 'compatibility'. 'strict' would conform as closely to
the spec as possible, and would therefore be essentially unusable for the
time being (presumably until Selenium 3 which I am assuming will conform to
the spec), and 'compatibility' would allow for tests to be written against
current WebDriver remote ends.

Does this seem like a reasonable strategy?

Marc

Received on Friday, 7 March 2014 20:57:12 UTC