IDL checked in

15 views
Skip to first unread message

Simon Stewart

unread,
Mar 5, 2011, 6:21:45 AM3/5/11
to selenium-developers
Hi everyone,

I've just checked in the first version of the proposed IDL for the
browser automation standard[1]. 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.

Cheers,

Simon

[1] http://code.google.com/p/selenium/source/browse/wiki/standard/webdriver.idl

Jim Evans

unread,
Mar 5, 2011, 11:21:36 AM3/5/11
to Selenium Developers
Where is the best place to submit comments? I have a couple.

--Jim
> [1]http://code.google.com/p/selenium/source/browse/wiki/standard/webdriv...

Simon Stewart

unread,
Mar 5, 2011, 6:41:50 PM3/5/11
to selenium-...@googlegroups.com, Selenium Developers
On the list is probably best, though you can also do a code review of the checked in revision. I'm happy with either.

Simon

> --
> 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.
>

David Burns

unread,
Mar 7, 2011, 5:57:55 AM3/7/11
to selenium-...@googlegroups.com
Few questions:

Are we going to split this up into multiple IDLs so we can show dependencies better?

Are we going to be keeping the value attribute? Since that is just getAttribute("value")? I have seen talk about this before and think that its a good idea to simplify it. 

Happy for us to start piling in with documentation?

David

David Burns
URL: http://www.theautomatedtester.co.uk/

Simon Stewart

unread,
Mar 7, 2011, 6:43:49 AM3/7/11
to selenium-...@googlegroups.com, selenium-...@googlegroups.com
On a plane about to take off so this will be short but I plan on following the html5 lead and interspersing docs and idl in a single (large) page. Feel free to make edits, though my first step will probably be to copy in the javadocs. 

Ditching the value attribute may be a good idea. You're right, we've talked about it before. 

Simon

Daniel Wagner-Hall

unread,
Mar 7, 2011, 7:34:32 AM3/7/11
to selenium-...@googlegroups.com, David Burns
I'm going to replicate my code review comments here :)

* I'm not sure about specifying value given that it's a shortcut for
getAttribute("value")

* 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.

David Burns

unread,
Mar 7, 2011, 8:14:54 AM3/7/11
to selenium-...@googlegroups.com
Daniel,

Where did you put your code review comments? I can't see any by the source. I ask because I have been expecting to see something from Jim as he had thoughts too.

Jim Evans

unread,
Mar 7, 2011, 9:28:06 AM3/7/11
to Selenium Developers
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?
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?

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).

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.

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.

--Jim

On Mar 7, 8:14 am, David Burns <david.bu...@theautomatedtester.co.uk>
wrote:
> Daniel,
>
> Where did you put your code review comments? I can't see any by the source.
> I ask because I have been expecting to see something from Jim as he had
> thoughts too.
>
> David Burns
> URL:http://www.theautomatedtester.co.uk/
>
> On Mon, Mar 7, 2011 at 12:34 PM, Daniel Wagner-Hall <dawag...@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
> > getAttribute("value")
>
> > * 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.bu...@theautomatedtester.co.uk>
> > wrote:
> > > Few questions:
> > > Are we going to split this up into multiple IDLs so we can show
> > dependencies
> > > better?
> > > Are we going to be keeping the value attribute? Since that is just
> > > getAttribute("value")? I have seen talk about this before and think that
> > its
> > > a good idea to simplify it.
> > > Happy for us to start piling in with documentation?
> > > David
> > > David Burns
> > > URL:http://www.theautomatedtester.co.uk/
>
> > > On Sat, Mar 5, 2011 at 11:41 PM, Simon Stewart <
> > simon.m.stew...@gmail.com>
> > > wrote:
>
> > >> On the list is probably best, though you can also do a code review of
> > the
> > >> checked in revision. I'm happy with either.
>
> > >> Simon
>
> > >> On Mar 5, 2011, at 4:21 PM, Jim Evans <james.h.evans...@gmail.com>
> >http://groups.google.com/group/selenium-developers?hl=en.- Hide quoted text -
>
> - Show quoted text -

Daniel Wagner-Hall

unread,
Mar 7, 2011, 10:47:27 AM3/7/11
to selenium-...@googlegroups.com, David Burns

David Burns

unread,
Mar 7, 2011, 10:50:14 AM3/7/11
to Daniel Wagner-Hall, selenium-...@googlegroups.com
Google Code fail. All that is visible to me is a +1 from Dave Hunt as you can see in the screenshot.

Screen shot 2011-03-07 at 15.48.25.png

Jari Bakken

unread,
Mar 7, 2011, 10:51:58 AM3/7/11
to selenium-...@googlegroups.com
On Mon, Mar 7, 2011 at 4:50 PM, David Burns
<david...@theautomatedtester.co.uk> wrote:
> Google Code fail. All that is visible to me is a +1 from Dave Hunt as you
> can see in the screenshot.
>

Yeah - I can't see any comments either.

Daniel Wagner-Hall

unread,
Mar 7, 2011, 1:46:45 PM3/7/11
to selenium-...@googlegroups.com, Jari Bakken
I'll remember never to use that feature again!

Clint Talbert

unread,
Mar 7, 2011, 6:42:24 PM3/7/11
to selenium-...@googlegroups.com
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... :( 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...
Clint

Simon Stewart

unread,
Mar 7, 2011, 9:46:12 PM3/7/11
to selenium-...@googlegroups.com, Daniel Wagner-Hall, David Burns
Inline

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
> getAttribute("value")

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.

Simon

Bill Ross

unread,
Mar 7, 2011, 10:05:35 PM3/7/11
to selenium-...@googlegroups.com
> > * 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.

Staying with the camelcase noun approach, how about PreferencesManager interface?

Bill

Simon Stewart

unread,
Mar 7, 2011, 10:06:02 PM3/7/11
to selenium-...@googlegroups.com, Clint Talbert
Hi Clint,

Answers inline

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
idea.

> First two cents...

Good to hear from you!

Simon

> Clint
> 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
>> getAttribute("value")
>>
>> * 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>
>>  wrote:
>>>
>>> Few
>

Simon Stewart

unread,
Mar 7, 2011, 10:19:31 PM3/7/11
to selenium-...@googlegroups.com, Bill Ross

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.

Simon

Simon Stewart

unread,
Mar 7, 2011, 10:38:54 PM3/7/11
to selenium-...@googlegroups.com
Inline. Thanks for the thoughts Jim.

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

Or for JavascriptExecutor, which is a fairly massive omission.

> 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
WebElement/RenderedWebElement interfaces.

> 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?

Simon

Jim Evans

unread,
Mar 7, 2011, 10:57:56 PM3/7/11
to Selenium Developers
Only from a "isn't quite as idiomatic of .NET as it could be"
perspective. Things like the IWebDriver.GetWindowHandle() method
should really be the IWebDriver.WindowHandle property. Stuff like
that. I should really get those properties and methods marked as
deprecated before 2.0b3. :)

On Mar 7, 10:38 pm, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> Inline. Thanks for the thoughts Jim.
>
> >> >http://groups.google.com/group/selenium-developers?hl=en.-Hide quoted text -

Daniel Wagner-Hall

unread,
Mar 8, 2011, 3:10:06 AM3/8/11
to Simon Stewart, selenium-developers, David Burns
On 8 March 2011 02:46, Simon Stewart <simon.m...@gmail.com> wrote:
>> * 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.

I was more seeing something like:

driver.cookies().add(someCookie) than
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 :)

Jason

unread,
Mar 8, 2011, 4:58:16 PM3/8/11
to selenium-...@googlegroups.com
Forgive me, but I'm not sure I understand why we would focus on the IDL first (or at all)?  What does the API for a client have anything to do with the behavior of the individual commands, let alone how a test would actually send commands to the browser?  I think we should focus on improving the wire protocol instead of trying to define a standard API.
Reply all
Reply to author
Forward
0 new messages