Re: W3C Python WebDriver local end

It is only a couple of lines of code in the Python local end also. In
addition, I have found other incompatibilities (most recently in Selenium
the location strategy is in the 'using' param, in the spec it is in the
'strategy' param), so it is probably necessary (at least for the
short-term) to identify the old vs. new.

Marc

PS I have the basic features of the Python WebDriver implemented. I want to
clean up the code some; my Python coding skills are a bit rough, and I did
a lot of experimenting as I implemented it. I should have a PR available by
the end of the week.



On Mon, Mar 10, 2014 at 4:57 AM, Seva Lo <vlotoshnikov@gmail.com> wrote:

> Just a naive idea... If it is mostly a matter of one level of nesting of
> the 'parameters' and it's no accident that spec is different from today's
> Java Selenium server and browser drivers Perhaps it is only a few lines of
> a change in Java Selenium server to start accepting 'parameters' at either
> level of the JSON payload?
>
> That could be a smaller change than one adding the compatibility mode to
> the W3C Python WebDriver. And Selenium Java has to become compliant with
> the spec eventually anyway.
>
>
> On Fri, Mar 7, 2014 at 1:08 PM, Luke Inman-Semerau <luke.semerau@gmail.com
> > wrote:
>
>> 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
>> >
>>
>>
>>
>