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

On 04/10/16 17:18, Simon Stewart wrote:
> The problem is if there is a clash between any of the property names of
> any object ever returned by any command in the spec now or in future
> revisions and the JSON object being returned. We worried long and hard
> about this with elements, which is why we moved from Selenium's
> "ELEMENT" name to the pseudo-GUID we have now. Also, if we ever return a
> map of hash from any method, there's no way to distinguish "returned by
> the driver" from "added as decoration"

I don't understand this. The only commands that returns arbitrary JSON 
blobs is execute*Script. This uses a "value" wrapper precisely because 
of this issue (or, conceptually, because it returns a single value that 
can be any JSON-representable object). Since commands don't return 
arbitrary keys, there is no possibility of clashes. ELEMENT-* was 
special precisely because it had to be seamlessly mixed into arbitrary 
JSON from script return values.


> I'd like to point out again that this is a far more consistent way of
> doing things, especially since the spec is currently a mixture of
> "return a raw object", "return a raw object as a value property" and
> "return a raw primitive as a value property". As a developer, that lack
> of consistency makes me consider the wealth of interesting bugs and edge
> cases that might occur.

I don't agree that adding a layer of value indirection where it isn't 
required adds more than superficial consistency here. You still need to 
know which fields to read for any particular response type, and the 
kinds of data to expect in them.

Received on Tuesday, 4 October 2016 16:49:19 UTC