Re: The ever contentious capabilities for new sessions

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.

Received on Wednesday, 14 September 2016 14:24:39 UTC