Re: W3C Python WebDriver local end

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
> >
>
>
>