I've just checked in the first version of the proposed IDL for the
browser automation standard. It's certainly not complete, but I
think it gives us something to have an ongoing conversation about.
Things that I am aware are missing:
* Any exceptions being thrown from methods
* Nothing that maps to the advanced user interactions API
* No mechanism for detecting the capabilities supported by a browser
* Anything equating to Command and Response
Those last two are fairly major omissions since they provide a
mechanism for actually creating something like the remote webdriver.
We'll fix that soon. Comments are welcome.
The next step will be to start hanging some documentation off this
(extremely bare) text.
> You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
> To post to this group, send email to selenium-...@googlegroups.com.
> To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.
* I'm not sure about specifying value given that it's a shortcut for
* Could TimeUnit be more strongly typed?
* Cookie handling seems strangely lumped together with meta driver
management - maybe we should pull out a Cookies or CookieJar interface
* TargetLocator.frame(String nameOrId); - nameOrId: Ick.
Yeah - I can't see any comments either.
Having a very generic name of "ManageOptions" or "Manage" or "Manager"
isn't really going to be helpful for new folks learning the API. I'd
prefer it to be more explicit, but I'm still rather unfamiliar with your
API so I can't suggest anything decent... :( Right now, it appears to
only manage cookies and timeouts. Can you break that into two
interfaces? ManageCookies & ManageTimeouts? If you did that would we be
flooded with Manage* interfaces? If there are going to be 10
Manage<foo> interfaces, then my solution is subpar.
First two cents...
On Mon, Mar 7, 2011 at 7:34 AM, Daniel Wagner-Hall <dawa...@gmail.com> wrote:
> I'm going to replicate my code review comments here :)
> * I'm not sure about specifying value given that it's a shortcut for
Good point. Removed.
> * Could TimeUnit be more strongly typed?
That'd be good. All I need to do is find the right WebIDL incantation.
Suggestions always appreciated.
> * Cookie handling seems strangely lumped together with meta driver
> management - maybe we should pull out a Cookies or CookieJar interface
CookieJar is a nice idea. I view the "Manage" interface as something
that maps to a browser's "Preferences" window.
> * TargetLocator.frame(String nameOrId); - nameOrId: Ick.
Well, agreed. Any alternatives? The one that leaps to mind is to
accept a Locator, though we'd need to clearly document which ones we
could pass in.
Staying with the camelcase noun approach, how about PreferencesManager interface?
On Mon, Mar 7, 2011 at 6:42 PM, Clint Talbert <ctal...@mozilla.com> wrote:
> I agree with all of this, especially the bits about the cookie management.
> Having a very generic name of "ManageOptions" or "Manage" or "Manager" isn't
> really going to be helpful for new folks learning the API. I'd prefer it to
> be more explicit, but I'm still rather unfamiliar with your API so I can't
> suggest anything decent... :(
In a way, it makes you the perfect person to comment :)
> Right now, it appears to only manage cookies
> and timeouts. Can you break that into two interfaces? ManageCookies &
> ManageTimeouts? If you did that would we be flooded with Manage*
> interfaces? If there are going to be 10 Manage<foo> interfaces, then my
> solution is subpar.
I view the Manage interface as the equivalent of the Preferences or
Options menu in a browser, providing access to underlying
functionality that's useful but harder to surface in the UI.
Currently, the only things that we're exposing in this way are the
cookies and timeouts. Daniel's idea of adding a "cookie jar" interface
maps into that quite naturally ---- almost all browsers have a
separate tab or control panel for managing cookies. In this case, my
gut feeling is that in this case, breaking out the cookies is a good
> First two cents...
Good to hear from you!
> On 3/7/2011 4:34 AM, Daniel Wagner-Hall wrote:
>> I'm going to replicate my code review comments here :)
>> * I'm not sure about specifying value given that it's a shortcut for
>> * Could TimeUnit be more strongly typed?
>> * Cookie handling seems strangely lumped together with meta driver
>> management - maybe we should pull out a Cookies or CookieJar interface
>> * TargetLocator.frame(String nameOrId); - nameOrId: Ick.
>> On 7 March 2011 10:57, David Burns<david...@theautomatedtester.co.uk>
One reason for picking the "manage" name is that it reads well:
"manage.cookies" and "manage.timeouts". Admittedly, there's no need
for the attribute name and its type to be the same, but there's a
pleasing symmetry to it. There's also a natural tension between
"perfect" names and those that mirror the existing code. To reflect
this, the name of the interface should really be Options. Quite what I
was thinking when I called it "Manage" I don't know.
On Mon, Mar 7, 2011 at 9:28 AM, Jim Evans <james.h....@gmail.com> wrote:
> I hadn't submitted anything yet. I'd planned to simply put my thoughts
> out here on the list, as per Simon's suggestion.
> To that end, my initial thoughts are as follows:
> I wholeheartedly, and enthusiastically support proposing a set of
> interfaces as a standard. Our job as creators of tools to enable
> testers create automated tests can only be made easier when we can
> point to a standard for browser vendors to adhere to. In doing so,
> however, we are opening the API up to a lot of scrutiny to a much
> larger audience than we have previously. How willing are we to adjust
> our IDL to the suggestions of the larger "web standards" community?
This process of standardisation is going to require a number of
compromises. Fortunately we're not trying to invent a standard API
using the awesome power of wishful thinking, we've got a fairly stable
API to build from. It means that the IDL will change, and that will be
reflected in our APIs, but we're not going to be making major changes
without discussion, and given the choice between a slightly nicer name
and stability in API, I'll almost always go for stability.
I'd appreciate being held to that :)
> Are we willing to break the existing API implementation, and by
> extension existing user code bound to the current version of the API,
> to conform to the IDL?
We've got an established way of changing APIs in the project already
(marking as deprecated, waiting a release, deleting as necessary) The
last really major renaming the project went through was when we
migrated the package name of the project to "org.openqa". It wasn't a
huge amount of fun, but it was manageable.
> Regarding the Manage and Navigate interfaces, I know these are the
> names of the methods in the Java implementation, but shouldn't the
> interface name be a noun? Looking through the other web standard IDLs,
> I don't see any interfaces with names that are verbs. Suggestions:
> OptionsManager and Navigator (though Navigator may be confusing, since
> it conflicts with an existing HTML5 interface name).
I've reverted it to Options, matching the name in the Java and .Net names.
> There is currently no IDL for RenderedWebElement, et al. I realize
> that the user interaction API isn't represented yet; I look forward to
> it being so, and some of the methods on these additional interfaces
> are subsumed by that API. I know that not every browser that we
> support renders content (I'm looking at you HtmlUnit). Nevertheless,
> it seems to me that we could benefit from formalizing and
> standardizing the additional interfaces. Perhaps some of this goes
> back to the discussion of what should really be represented in the
> WebElement interface and whether it makes sense to reorganize the
> RenderedWebElement and Locatable interfaces.
Agreed. We're not far from beta 3, but once that's out the door, I
suggest we start making the modifications to the
> I can see now through the formalization of the IDL that several things
> that are currently methods in the .NET bindings should, in fact, be
> read-only properties. I need to figure out whether to make the
> changes, and if so, how to properly communicate these breaking changes
> to the user base.
Are there any that stand out in particular?
I was more seeing something like:
driver.manage().cookies().addCookie(someCookie) - I view cookies as a
more cross-concern issue than just preferences management (they're
things I care about on specific pages more than in a preferences
management way), but I'm happy to be argued against :)