Re: W3C Python WebDriver local end

Yes, to me it does. +1 for allowing a run-time defined strict or
compatibility mode (compatibility being the default for now)

On Fri, Mar 7, 2014 at 12:56 PM, 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
>

Received on Monday, 10 March 2014 10:23:45 UTC