- From: Marc Fisher <fisherii@google.com>
- Date: Fri, 7 Mar 2014 12:56:24 -0800
- To: public-browser-tools-testing <public-browser-tools-testing@w3.org>
- Message-ID: <CAEqLoMg3Oh6Saf61KssOmMRgZhsGC=syzJo3bP2xSf5orvyEpA@mail.gmail.com>
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