--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/655d8c4b-b153-429d-91b6-d9933c0c09ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi,
1) Deprecation is not deletion. If someone (say, SalesForce) just start to use WebDriver API they should see what constructors are recommended and what are not.
2) BrowserOptions interface is required to be able to implement a type safe methodRemoteOptions.setBrowserOptions(BrowserOptions options)
3) BrowserOptions interface can demand all implementing classes to have toCapabilities() method, or toJson() method or toMap() method, whatever is more suitable to serialize this object for transmitting it over the wire.
4) BrowserOptions can have a method setCapability() to pass an arbitrary capability, but if there a type-safe method in the same class suggested by auto-completion -- I'm sure users will prefer more specific methods.
5) BrowserOptions can have (and sometimes already have, e.g. via FirefoxBinary) a method to set browser CLI switches (like '-headless'), at the same time we can provide type-save methods for frequently used switches (like '-headless')
Regrads,--
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsubscribe...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/655d8c4b-b153-429d-91b6-d9933c0c09ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/82731437-5ed5-44e8-9e94-4adcb8a014bc%40googlegroups.com.
I've been making this argument for quite some time now, and have been moving parts of the project for which I'm responsible in the direction of a type-safe API. I fear Simon and I fundamentally disagree on this subject on a couple of points, and I don't see us reconciling our views on that anytime soon.
I don't believe the existence of an "escape hatch" to be a problem. If a user has to use it, they should do so knowing it's a temporary workaround until a type-safe alternative is available. In the .NET case, if you try to use the escape hatch (the AddAdditionalCapability method), and you use a string that's a known capability name for which there is a type-safe alternative, you'll get a runtime error with a very clear message. Yes, that means some users may have to change their code after updating to a new version of Selenium, but I don't see that as a Bad Thing on the face of it[1].
Having said that, I'm not necessarily opposed to having the Options classes implement the Capabilities interface. The interface is read-only, and doesn't allow setting of capabilities anyway.
To my mind, the main missing piece is a construct to allow the user to create a spec-compliant remote new session request that may have the complex matching rules the spec allows. Also, the construct needs a mechanism for third parties (cloud providers, other intermediate node projects, etc.) to add their required pieces to the request. I created a straw man, proof-of-concept prototype just to see what such an API would look like for .NET, and while there are things that need refinement, it's not too bad.
I'm less concerned about allowing any arbitrary version of the language bindings being able to seamlessly talk to any random remote end. Putting a stake in the ground and saying, "You need at least version X to play nice," is not out of line, as far as I'm concerned. I know I'm at odds with some on that, but I doubt I'll be changing my (or anyone else's) mind.
[1] That's an argument I'm willing to have over a pint sometime. I'm not doing it here.
[2] https://github.com/jimevans/webdriver-remote-api-prototype
Let's leave Salesforce out of this, if you please. Our reasons for delaying our upgrade have little to do with technical complexity.
I've been making this argument for quite some time now, and have been moving parts of the project for which I'm responsible in the direction of a type-safe API. I fear Simon and I fundamentally disagree on this subject on a couple of points, and I don't see us reconciling our views on that anytime soon.
I don't believe the existence of an "escape hatch" to be a problem. If a user has to use it, they should do so knowing it's a temporary workaround until a type-safe alternative is available. In the .NET case, if you try to use the escape hatch (the AddAdditionalCapability method), and you use a string that's a known capability name for which there is a type-safe alternative, you'll get a runtime error with a very clear message. Yes, that means some users may have to change their code after updating to a new version of Selenium, but I don't see that as a Bad Thing on the face of it[1].
Having said that, I'm not necessarily opposed to having the Options classes implement the Capabilities interface. The interface is read-only, and doesn't allow setting of capabilities anyway.
To my mind, the main missing piece is a construct to allow the user to create a spec-compliant remote new session request that may have the complex matching rules the spec allows.
Also, the construct needs a mechanism for third parties (cloud providers, other intermediate node projects, etc.) to add their required pieces to the request. I created a straw man, proof-of-concept prototype just to see what such an API would look like for .NET, and while there are things that need refinement, it's not too bad.
I'm less concerned about allowing any arbitrary version of the language bindings being able to seamlessly talk to any random remote end. Putting a stake in the ground and saying, "You need at least version X to play nice," is not out of line, as far as I'm concerned. I know I'm at odds with some on that, but I doubt I'll be changing my (or anyone else's) mind.
[1] That's an argument I'm willing to have over a pint sometime. I'm not doing it here.
[2] https://github.com/jimevans/webdriver-remote-api-prototype
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/f7ee3d12-cc6e-4bf2-b0a9-e850ccff9eb4%40googlegroups.com.
After some chatting on IRC, let me correct the suggestion:1) We should allow to use any information contained in payload to match a node.That means, if we have a class RemoteOptions, or W3CCapabilities, we should allow to do something likecapabilities.setFirstMatch(new FirefoxOptions().setHeadless(true))and the grid might use this information to choose a node that is able to run headless Firefox.
That means, there is no strict border between "capabilities" and "options". Such is the spec.In view of this fact, yes, it makes sense to inherit options classes from Capabilities or even MulableCapabilities.
If we implement this inheritance, we should (contrary to my suggestion) deprecate and delete in future constructors that accept browser specific options classes. Users can use FirefoxDriver(Capabilities desiredCapabilities) constructor to pass either MutableCapabilities or FirefoxOptions parameter.Unfortunately, this solution in itself will not encourage people to use FirefoxOptions. So we can just put irate messages to the log as a soft motivation to migrate to a better solution.
2) At the same time we need a new class (RemoteOptions, or W3CCapabilities) to generate valid W3C conformant payload with alwaysMatch, firstMatch and other whistles required for cloud providers and custom grid makers.
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/189103f0-5c8d-4331-a0fc-7909159fabb1%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/189103f0-5c8d-4331-a0fc-7909159fabb1%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYF3adxxzDFfErL6Ga7Hzwr4%2BmF7D8DsgUn_8K86M%2BhtGA%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/189103f0-5c8d-4331-a0fc-7909159fabb1%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYF3adxxzDFfErL6Ga7Hzwr4%2BmF7D8DsgUn_8K86M%2BhtGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAP_8%3DB6Jwd7fVU0uYpynq1_gapVB37pFajEUt099kaB3zmDxCQ%40mail.gmail.com.