Re: The ever contentious capabilities for new sessions

> On 14 Sep 2016, at 15:24, 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

The only node in the system that's capable of fully knowing which settings it's capable of handling is the node itself. It's also not safe to assume that your intermediary node can remove data, in case there's another intermediary node in the route that also needs this information. 

The only way an information deleting design such as the one you propose would work is if all webdriver implementations had complete knowledge of the next node being routed to, and this knowledge was correct. This hasn't always been true IME. 

As an example, I've recently been switching code between the OSS firefoxdriver, geckodriver, the edgedriver, and a small single node grid with those same drivers, all with scant regard for what the next node I'm communicating with is. The current design of capabilities has meant that the servers haven't needed to be modified to support this. 

Simon