Re: Response data should always be in a top-level "value" property.

I should point out that all implementations other than geckodriver
currently return values wrapped in a "value" property as they implement the
json wire protocol. The suggestion leads to less coding for them too.

Simon

On Sat, Oct 1, 2016 at 12:44 PM, Simon Stewart <simon.m.stewart@gmail.com>
wrote:

> Hi,
>
> Proposal: any response from an end node that contains data should put that
> data in a "value" property of a JSON object.
>
> Rationale:
>
> I've been working on improving W3C compliance in the java local end for
> selenium, as well as writing a lightweight intermediate server
> implementation that streams results where necessary. From this work, it
> seems like the current spec is less consistent and requires more processing
> work on local ends than the existing JSON wire protocol used by OSS
> WebDriver.
>
> Notably, the JSON wire protocol always returns the value from a command in
> a top-level property called "value". The W3C spec mostly does this too, except
> when it doesn't
> <https://github.com/SeleniumHQ/selenium/commit/aa25e5443d29694aa30fd25786a2e85b03262f20#diff-f0a832e4423040d26443b974309b65a3R44>.
> This has a number of drawbacks:
>
> 1) Processing the result cannot be a two stage process of dumbly
> extracting the return value and then coercing to a type. Instead, local
> ends must know the command being responded to (information not included in
> the response) and switch behaviour as appropriate. This additional
> complexity is needless.
>
> 2) It's inconsistent. Generally, inconsistency is where bugs live.
>
> 3) It precludes decorating responses with additional information, since we
> cannot know for sure whether the response is one of the ones with a "value"
> field, or one where the response body is the data itself.
>
> 4) It's a needless divergence from the JSON wire protocol.
>
> The suggested proposal, of always using a "value" field, resolves all of
> these issues. The alternative (of never using a "value" field, but instead
> always pushing the result data directly into the body of the response)
> fails to resolve issues 3 and 4, which seems less than ideal.
>
> Simon
>