This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Intermediary nodes will be allowed to accept more than a single session to be stored, and they consequently need to keep a list of currently active sessions. Final remote ends may only support a single session at a time and thus needs a concept of "maximum number of sessions", which we can check against the length of "known sessions" to see if we can start a session or not. This spun out of the discussion in https://github.com/w3c/webdriver/pull/9#discussion_r24584781.
I thought we had decided not discuss/consider intermediary nodes at all in this spec. Additionally, do the intermediate nodes need to be able to query this? If the maximum number of sessions for a remote end has been reached, then an attempt to create a session will fail, which should just propagate back through all intermediates (with them acting appropriately).
(In reply to Marc Fisher from comment #1) > I thought we had decided not discuss/consider intermediary nodes at all in > this spec. Well, intermediary nodes should be conforming implementations of the specification. If you interact with a remote that you know is compliant you can make assumptions about its behaviour, and if it doesn't behave as expected it's clear it has bugs. In terms of the external API an intermediary has to be indistinguishable from a “furthest remote”. But that means that in order to allow us to specify that API in detail we have to allow for cases that apply to intermediaries but not to furthest remotes, or vice-versa. E.g. a single browser will only have a single active session, so there has to be an error if you try to create a new session when one is already active. But since intermediaries may have multiple active sessions they don't need to produce the same error. > Additionally, do the intermediate nodes need to be able to query this? This would be a state associated with the intermediary remote node itself. For intermediaries the value might be "unlimited", whereas for the final remote (the driver implementation) it might be 1. > If the maximum number of sessions for a remote end has been reached, then > an attempt to create a session will fail, which should just propagate back > through all intermediates (with them acting appropriately). Exactly.
Right. I was a proponent of saying "an intermediary is just a thing that implements both the local end and the remote end of a specification". But I'm now not sure that works in detail. For example, as in this bug, you need a way to explain the fact that a browser can only have one active session, but a proxy system might be able to fire up an unlimited number of browsers, so in the first case you have to fail if there's already a session, but in the second you don't. Even with a browser isn't not impossible that you want to allow more than one connection at a time for some reason. In the longer term we may have to have some specific text to point out that if you are an intermediary node you don't need to actually perform the steps for each command in the spec, but can proxy to another node that does perform the specs in the spec.
Some real life "furthest remote" servers allow more than one session: chromedriver.