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

I don't disagree with this proposal.

Worth noting that this was previously litigated at TPAC 2014
<https://www.w3.org/2014/10/30-testing-minutes.html#item05>, where there
were two related resolutions:
> resolution: remove response body and just send back dictionary
> resolution: use 'value' key for primitives

I think the order of events was:
- the response used to have a "status" field and a "value" field
- the "status" field was removed in favor of using HTTP status codes
- the "value" field was removed for non-primitive responses because it
seemed redundant to wrap the response in '{"value": ... }'

I can't quite recall whether there were other arguments for "unwrapping"
the response, other than that it seemed unnecessary at the time.

I think the consistency argument (#2) alone is more compelling than that.
Point #3 is also kind of nice; it allows for future protocol modifications
to add additional fields, should that become necessary.

On Sat, Oct 1, 2016 at 5:23 AM, Simon Stewart <simon.m.stewart@gmail.com>
wrote:

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