- From: Andreas Tolfsen <ato@mozilla.com>
- Date: Wed, 5 Oct 2016 18:02:50 +0100
- To: public-browser-tools-testing <public-browser-tools-testing@w3.org>
- Cc: Simon Stewart <simon.m.stewart@gmail.com>
Sorry I’m late to the party (-; Simon Stewart <simon.m.stewart@gmail.com> writes: > Proposal: any response from an end node that contains data should put > that data in a "value" property of a JSON object. Most importantly, I think this is a very late and untimely change to make if we want to see the specification in CR-state by end of January. I was under the impression that the fundamental design of the protocol would not change; especially not on a decision that was made—at a F2F none the less—over two years ago. Mozilla has put a lot of engineering resources into adapting our implementation to the current definition. Changing it now will require a non-insignificant investment on our end. I’ve done the backwards compatibility dance around this before, and I’m hesitant to do it again for what I perceive as only aesthetic changes. > 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. A client will always need to have some level of knowledge of the data structure that is returned. If they blindly accept whatever the server sends, they may break the API contract they give to consumers. I buy the argument that it is easier for intermediaries to deal with an object where the return value is always encoded in the same place because they may not care about the data itself. But on the other hand I think it is entirely reasonable for the local end to know more about the protocol it is implementing. For the ‘Set Timeouts’ and ‘Get Element Rect’ commands, any local end will inevitably have to look up specified keys in the returned JSON Object before it presents it to the user. Whether you do this through some automatic JSON decoder codec (for which you could have one for W3C and one for Selenium) or manually is besides the point, because at some level it needs to know something about the protocol data structure. > 2) It's inconsistent. Generally, inconsistency is where bugs live. I think the idea of wrapping everything inside a ‘value’ field has a whiff of structured XMLness over it. It might make the task of writing the W3C WebDriver-to-Selenium WebDriver shim easier, but at some level a client and a server needs to know certain details about what structures and types are returned so I don’t think it changes anything other than perhaps giving the code in Selenium a somewhat nicer appearance. My tl;dr on this is that I’m _not strongly opposed_ to the change as such, but I’d like us to think very carefully about whether we think it is necessary. I agree with James that because it only creates another level of indirection, I too fail to see what it earns us apart from a certain aesthetic symmetry. Moving a specification to Rec requires at least two conforming implementations, and it will take time to change geckodriver and potentially the Marionette automation protocol. Because of this I think there is a distinct chance that the January CR deadline will slip.
Received on Wednesday, 5 October 2016 17:23:22 UTC