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

Inline

On Mon, Oct 3, 2016 at 9:00 PM, Jason Juang <juangj@google.com> wrote:

> 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 can't remember either, but I suspect that we overlooked the case of
wanting to decorate responses in the way that we can already decorate
requests, and this seemed relatively efficient.

There are some problems with JSON parsers not being able to parse raw
responses, so the spec has to return an object anyway for some calls, and,
because the spec is descended from the JSON wire protocol used by the
selenium project, many of the commands already return a "value" property
anyway,


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

Agreed :)

Simon


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