Re: Proposal: Setting all capabilities to required

One issues with

> ... we need to make it clear that any intermediary expecting a capability
needs to pop this off the capabilities object before the command is proxied
on to the next remote.

If the intermediary does that, then:
The "next remote", not having that capabilityX in the requested set of
capabilities, may "know about" that capability, too (and possibly be
capable of providing that capability).
Then, since the capability is not explicitly requested as far as the "next
remote" can see, it may (and should be allowed by the spec) explicitly
switch it off, and return {..., capabilityX: false} in the "actual"
capabilities.
Having received that capabilityX:false from the "next remote", and
depending on the semantics of the capability, the intermediary node may
have an unsolvable problem.

Of course, something like that can only be an actual problem only if there
is a capability that conceivably be implemented by an intermediary and/or
by a "final" remote end AND that an intermediary loses the ability to
implement/provide that capabilityX if the "next remote" started a session
with capabilityX:false. I don't have a real example of that offhand (but I
know examples of features/capabilities that can be provided by an
intermediary as well as a "final" remote; one such example is: blow up
whenever certain text/cssSelector is found/matched in current DOM).

Of course, not doing what Andreas said ("...pop this off the capabilities
object before the command is proxied on to the next remote") is not going
to solve this problem.

Seva

On Wed, Oct 22, 2014 at 5:04 PM, David Burns <dburns@mozilla.com> wrote:

> On 22/10/2014 11:27, Andreas Tolfsen wrote:
>
>> Attempt to bring this thread back on topic.
>>
>> On Thu, Oct 2, 2014 at 3:11 PM, David Burns <dburns@mozilla.com> wrote:
>>
>>> I would like to propose that in Section 4.1 we remove desiredCapabilites
>>> and
>>> requiredCapabilites and just have a capabilities object. This
>>> capabilities
>>> object would then be treated as a requiredCapabilities object and if any
>>> of
>>> keys in that object do not match what the UA/intermediary node can do
>>> then
>>> error with a `session not created` status. If keys have been omitted from
>>> the capabilities object then the UA/intermediary node can just assume
>>> that
>>> the developer is happy with whatever they receive
>>>
>> What about additional capabilities that are unknown to the driver?
>>
>> There is a use case for passing along purely informational
>> capabilities, such as a profile or some special string you would like
>> the remote or any intermediary remote to pick up.
>>
>
> I have written a patch where this is information is stored in the remote
> end. I think it could be useful for keeping a bit of info for the local end.
>
>
>> When I read this initially I thought that the driver would only return
>> an error when failing to match the capabilities it knew about; not
>> that it would also fail on _any_ unknown capability.
>>
>
> This is what I think we should fail on capabilies that the it knows about.
>
>
>> If this indeed is the desired behaviour we need to make it clear that
>> any intermediary expecting a capability needs to pop this off the
>> capabilities object before the command is proxied on to the next
>> remote.
>>
>
> Good point, I will add that.
>
>
> The other ommission from where is there currently is what if we want the
> capability to mutate something on the serverside. For example, you want to
> turn off SSL pass through for self-signed certs. Currently if you pass in
> secureSsl : false that will in the current spec throw an error if the UA
> has `secureSsl : true` internally.
>
> Should we have a specific key that contains all caps that can be mutated?
> e.g. caps = {secureSsl: "yup", mutable: {secureSsl: false}}
>
> David
>
>