New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specifying extension commands with no "name" #1170

Closed
jugglinmike opened this Issue Dec 6, 2017 · 1 comment

Comments

Projects
None yet
1 participant
@jugglinmike
Contributor

jugglinmike commented Dec 6, 2017

In our efforts to integrate the WebDriver in the Permissions specification, we've identified a need that isn't addressed by the "protocol extension" mechanism today: defining a command that has no associated name.

In this case, we're looking to support setting a Permission in automation. We'd like to define a command for the HTTP POST method to the URI template /session/{session id}/permissions.

The definition of the "extension command prefix" defines its intent as: "separating extension commands from other commands in order to avoid potential resource conflicts with other implementations." Based on this definition, session/{session id}/permissions seems like the correct choice, but in this case, there is no particular "name" we'd like to assign.

We could circumvent this by defining the "prefix" as session/{session id} and the "name" as permissions, but this conflicts with the stated intent of those segments.

I'd like to propose that the "extension command name" be made optional. Beyond documenting it as such, I believe the only other change to the WebDriver specification text would be in the instruction for how the "extension command URI Template" is constructed.

Would this be acceptable to the editors?

jugglinmike added a commit to bocoup/webdriver that referenced this issue Dec 22, 2017

Generalize protocol extension mechanism
The facilities offered for protocol extensions are intended to be used
by both web standards and browser vendors. Prior to the application of
this commit, the specification text inconsistently described these two
distinct use cases [1]. The mechanism itself was biased towards the
"browser vendor" use case because it required the specification of an
"extension command prefix" which is not appropriate for all "web
standards" use cases [2].

Explicitly describe both use cases in the informative text and
generalize the normative text to better-support extensions by web
standards.

[1] w3c#1142
[2] w3c#1170

andreastt added a commit that referenced this issue Jan 6, 2018

Generalize protocol extension mechanism (#1177)
The facilities offered for protocol extensions are intended to be used
by both web standards and browser vendors. Prior to the application of
this commit, the specification text inconsistently described these two
distinct use cases [1]. The mechanism itself was biased towards the
"browser vendor" use case because it required the specification of an
"extension command prefix" which is not appropriate for all "web
standards" use cases [2].

Explicitly describe both use cases in the informative text and
generalize the normative text to better-support extensions by web
standards.

[1] #1142
[2] #1170
@jugglinmike

This comment has been minimized.

Show comment
Hide comment
@jugglinmike

jugglinmike Jan 17, 2018

Contributor

We resolved via gh-1177 😸

Contributor

jugglinmike commented Jan 17, 2018

We resolved via gh-1177 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment