Fwd: The ever contentious capabilities for new sessions

And now to everyone. *sigh*

---------- Forwarded message ----------

Hi,

Authors of client libraries are definitely not going to be happy,
especially since there's no way for the local end to know whether it's
talking to an end node or an intermediary node.

My read of the PR is that when processing the capabilities, end nodes are
only ever looking at one set of capabilities at a time, iterating over each
possible capability in turn. If we get the language right, we stop on the
first match. Avoiding recursive merging of capabilities makes the merge
incredibly easy to write.

Simon

On Wed, Sep 14, 2016 at 3:24 PM, James Graham <james@hoppipolla.co.uk>
wrote:

> On 13/09/16 22:14, James Graham wrote:
>
> So I think a design similar to this that I would prefer is:
>>
>> {
>> "routing": [
>>   {"browser": "firefox",
>>    "platform": "linux"},
>>   {"browser": "firefox"},
>>   {"browser": "chrome"},
>>   {}
>> ],
>> "settings": [
>>     {"timeouts": {"script": 30000},
>>     {"match": {"browser": "firefox", "version": 49},
>>      "firefoxOptions": {"prefs": {"dom.disable-open-during-load":false}}
>>     },
>>     {"match": {"browser": "firefox"},
>>      "profile": <base64String>
>>     },
>>     {"match": {"browser": "chrome"},
>>      "binary": "/usr/local/chrome"}
>>   ]
>> }
>>
>> For any intermediary that did routing this would express a preference
>> for Firefox on Linux, followed by Firefox on any platform, followed by
>> Chrome, followed by anything.
>>
>> For browser settings, the options that match would be cumulative, so any
>> browser would set the script timeout to 30s, any firefox would use the
>> same base profile, firefox 49 would set a specific pref, and Chrome
>> would use a specific binary. For matching with the version number one
>> would have to use the specified binary, if any so e.g.
>>
>> {
>> "settings": [
>>   {"timeouts": {"script": 30000}},
>>   {"match": {"browser": "firefox", "version": 49},
>>              "binary": "/home/user/firefox"}
>>   ]
>> }
>>
>> running in firefox would only use the /home/user/firefox binary if that
>> binary was a firefox 49 binary (if intermediary nodes could be required
>> to edit the new session payload we could sidestep this complexity by
>> requiring that they reduce the settings to a list of length 1 with no
>> match clauses representing only the things that are known to work. But
>> that does have the problem that one can't send the same message
>> irrespective of whether a routing intermediary is present).
>>
>
> I think one alternative to this design would be one in which end nodes
> only saw settings which they were capable of handling, with routing
> intermediaries being required to handle collapsing down a list of settings
> into one. So an end point might just see
>
> {
> "settings": {"binary": "/usr/bin/firefox",
>              "profile": "<base64String>",
>              "timeouts": {"script": 30000}}
> }
>
> I think the main theoretical argument against this is that it would force
> clients to send a different message structure when talking to routing
> intermediaries, which require different settings per possible end point,
> compared to when talking to an end node directly. I don't know if this is a
> problem in practice, but I intuit that authors of client libraries aren't
> going to be very happy at exposing this distinction.
>
>
>