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

On Tue, Oct 4, 2016 at 6:00 PM, James Graham <james@hoppipolla.co.uk> wrote:

> On 04/10/16 17:23, Simon Stewart wrote:
>
>> On Tue, Oct 4, 2016 at 12:03 PM, James Graham <james@hoppipolla.co.uk
>> <mailto:james@hoppipolla.co.uk>> wrote:
>>
>>     On 04/10/16 11:16, Simon Stewart wrote:
>>
>>         Alright. Since we seem to be in broad consensus, I've put up a
>>         PR for
>>         this: https://github.com/w3c/webdriver/pull/345
>>         <https://github.com/w3c/webdriver/pull/345>
>>
>>
>>     So far we have one positive and one negative response. That doesn't
>>     seem like "broad consensus" unless there is some out of band
>>     discussion that I'm unaware of.
>>
>>
>> I'm confused. Who's the negative response from? You've said, and say so
>> again in this email, that if this is something worth changing you won't
>> object. That's more of an abstention :)
>>
>
> I am negative on this change at this time.


Noted.


>
>     As I said, if this is really something that people think is worth
>>     changing I won't object. But at this stage I really think reversing
>>     an explicit years-old consensus decision about a fundamental part of
>>     the protocol design should require actual "broad consensus" which
>>     means getting explicit approval on the list from most implementors.
>>     If there is no bar to revisiting old decisions we will never get done.
>>
>>
>> We've also said that if we find problems when implementing the spec, we
>> should resolve those issues in the spec. As someone implementing a local
>> end, and more than one intermediary node, I've identified a problem, and
>> we should fix that.
>>
>
> My concern is that an editor of the spec, who can be presumed to have a
> good understanding of its contents, is now revisiting an decision that was
> taken two years ago without anything that seems like new information. I
> struggle to see this issue as a bug fix based on implementation experience,
> rather as a late-expressed aesthetic preference.
>

I hear you, and I understand your concern.

The new information I bring is that I'm now implementing a local end that
attempts to conform to the spec, and perhaps I didn't make that clear
enough. The way the spec is currently written adds unnecessary complexity
to that code, and fixing things up means passing information between layers
in the system that wasn't required before as the processing model is now
more complicated than the equivalent in the selenium json wire protocol.
The python and ruby implementations of the local end also get the
processing wrong. It obviously something that local end developers are
finding hard to use.

The .Net code takes a pragmatic but incorrect approach of sniffing for a
"value" property, and if that's missing assuming that the entire response
is the value to return to the user, which may not be true.

If the people closest to the spec implementing local ends get it wrong,
then that's not a great sign.

In addition, I've already found differences between what the spec says and
what geckodriver does. If the most widely used end node that attempts to
follow the spec doesn't conform to it, then clearly it's also tricky to get
this right in the end node too.

Of course we can work around these problems, and of course we can add tests
and be careful. Of course we can specify that properties of returned blobs
must never contain a colon. Those things are all possible, but by switching
to a simpler model we can avoid a whole class of problems, and make local
end implementations simpler.


> Now, if the working group agrees that the previous consensus was wrong for
> whatever reason that's fine, let's make the change with all due haste. But
> I want people to take the idea that the spec is going to get finished
> seriously. That means not randomly reopening old discussions except for
> compelling technical reasons.
>

And I agree with you. We just happen to differ on our perception of the
weight of this point. I do believe it's an important issue, and not just an
aesthetic one.

Simon