Re: W3C Python WebDriver local end

On my phone but I've been adding support for both strings and numbers as status codes to the standalone selenium server for a while. Try testing against that rather than a browser directly. 

We should probably allow an empty payload to indicate an empty response but I can see the argument for consistently returning an empty Json object. 

Finally, the selenium server is pretty generous about what it accepts. Add the command name and session I'd and I bet it'll work. 

Simon

Sent from my iPhone

> On 7 Mar 2014, at 20:56, Marc Fisher <fisherii@google.com> wrote:
> 
> 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-commands the 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-codes the 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
>