client library self-reporting caps

[Jonathan Lipps]

Proposal for new desired capabilities used for clients to report their identities to the server

Hi Selenium devs! I've got an idea I wanted to run past you guys. What are your thoughts?

Motivation:

Several scenarios are enabled when data about WebDriver client libraries can be captured. Let's say you're the maintainer of a large Grid at a company, used by many different departments. It would be useful to know the breakdown of the client libraries your colleagues are using. As Grid maintainer and Selenium aficionado, you know when a version is released that has a bug. You can systematically eliminate use of that buggy version when you see it making connections to your Grid. You can suggest upgrades. You can suggest alternate libraries using the same language. You can discover that two teams using JavaScript are using three different client libraries, and suggest a meeting to choose one approach. More generally, it might be interesting simply to gather statistics about what languages and libraries are being used. It would also be possible, of course, for the Selenium Server itself to make use of this information and output deprecation warnings, or otherwise take into account the client's identity (not that this would be a good thing to do in general, but it might be useful in special cases).

Data structure:

I would argue that at minimum we would need two pieces of information about each client that wants to report itself:

- a unique url identifying the client (perhaps the GitHub url of the project, or the project's website)

- the version of the client

We might allow other optional bits of data:

- name of the project

- git SHA of the current revision (or this could be appended to the version for development builds)

- programming language the client utilizes

- the platform of the requestor

This suggests that a hash is the best structure for the client identity. However, in some cases we might want to allow the flexibility of reporting for multiple clients simultaneously. For example, my project Yiewd[1] is an extension to the Node WebDriver client Wd[2]. Thus it would be useful to report not only the fact that the session request is coming from Yiewd, but that it is also coming from Wd. There are probably other cases where multiple tools are used to generate the session request, and these could all be usefully tracked. So I recommend an array of hashes as the data structure.

Proposal

So ultimately I propose a new capability requestOrigins, which is an array of one or more hashes. Each hash must have the following keys: url, version, the values for both of which are strings. Optional keys are: name, language, platform, and sha, also all strings.

Example

{

    browserName: "Firefox",

    requestOrigins: [{

        url: "https://github.com/admc/wd",

        version: "0.32.5",

        platform: "Mac OS X 10.9",

        language: "JavaScript",

        name: "Wd.js"

    }, {

        url: "https://github.com/jlipps/yiewd",

        version: "0.3.5",

        name: "Yiewd"

    }]

}

How do people feel about adding this to the set of desired caps? Any feelings about the specific keys/values? I'm very open to revision on the specifics. I'd be happy to contribute time to getting the official client libraries reporting themselves using this approach.

Cheers,

Jonathan

---

[1] https://github.com/jlipps/yiewd

[2] https://github.com/admc/wd

[David Burns]

I feel like I might be missing something here but this looks like it would only be of use to a IaaS (like your employer) since projects would be managing their dependencies in the project. At Mozilla we update client bindings and server all together. I know Google just use the version in their tree.

Is this a major issue for most of our users?

David

David Burns
Email: david...@theautomatedtester.co.uk
URL: http://www.theautomatedtester.co.uk/

--
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/5B2AAD48-A274-450F-AAB8-D11FDA184F14%40saucelabs.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jonathan Lipps]

Yes, the reason this came up as an idea for me is that something like this would be useful to my employer (or other service platforms built on Selenium). However I don't think the benefit stops there, which is why I gave a motivating scenario or two that to me could plausibly obtain outside of the cloud service context (e.g., in a large organization whose Selenium cloud operated as an internal service).

But no, I don't think this addition provides a huge amount of value to the individual user of Selenium. It could make it easier to reproduce bug reports (say for example if the server output this information in its log), but the primary value is for grids or cloud services for whom statistical data about clients would be useful.

Jonathan

To unsubscribe from this group and stop receiving emails from it, send an email to selenium-developers+unsub...@googlegroups.com.

[Simon Stewart]

This is going to be a dumb question, but bear with me: why not just bolt this information in when someone uses SauceConnect?

Simon

On Fri, Feb 21, 2014 at 1:43 AM, Jonathan Lipps <jli...@saucelabs.com> wrote:

--

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.

[Jonathan Lipps]

Not a dumb question. However it'd only be possible (a) with the new version of SauceConnect, and (b) if people actually use the c extension within their preferred language (all of these are currently work in progress). If instead they use the binary on its own, I don't think SC would have a clue what the origin of the requests are; it's just a happy little proxy.

Another reason is that SauceConnect is not always running when people are using Sauce (bad security practice though that may be).

Thanks for the suggestion. It's more than nothing to work with, but stats would likely be skewed in a way my data-loving heart would find sad.

I guess another question to keep this conversation moving is: if my team is willing to do the work to implement the proposal, are there any other objections?

Jonathan

You received this message because you are subscribed to a topic in the Google Groups "Selenium Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/selenium-developers/Zj1ikTz632o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/CAOrAhYGkrwWurBdaPF%2BgYyCz8fpfoqkVe3hmZZ9Y06D4_aEjEQ%40mail.gmail.com.

[Jonathan Lipps]

Two and a half years later, I find myself still missing this feature. I think it would be useful for managed grids or cloud services that want to gather data about the distribution of clients. I also have ideas about even more interesting data the clients could report to the remote end, but I'll save that for now as I don't want to overwhelm you :-)

And I'll repeat what I said earlier: my team would be happy to do the implementation work!

Jonathan

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/5B2AAD48-A274-450F-AAB8-D11FDA184F14%40saucelabs.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "Selenium Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/selenium-developers/Zj1ikTz632o/unsubscribe.

To unsubscribe from this group and all its topics, send an email to selenium-developers+unsub...@googlegroups.com.

[Aaron Evans]

It seems to me that this is just one use case of a more general feature -- the ability to send metadata along with a session. 

DesiredCapabilities might not be best way to shoehorn it in, but it's there and it's easily extensible without breaking backwards compatibility.  

I could come up with several scenarios besides jlipps' example, especially if you think of the JSON wire protocol as more than just a way to communicate between a test case and a Selenium server.  And there could be lots of reasons to send additional (especially identifying) information.  An authorization scheme is one example, but also other behaviors that are not browser or test case specific.  

What about home automation controls? I'd need a way to specify in metadata which appliances I can drive with Selenium and how to access them.

DesiredCapabilities caps = new DesiredCapabilities();

caps.add("metadata", HomeAutomationHash);

driver = new HomeAutomationDriver(capabilities);

driver.findElement(by.Metadata(alarm)).snooze(15 * 60 * 1000);

driver.findElement(by.Metadata(coffee)).start();

driver.findElement(by.Metadata(shower)).warm();

So my suggestion is for a general metadata field that can be added to capabilities that will allow further extension beyond the current use case of tracking client libraries and users.  Then each implementor could specify their own metadata structures.

[Jonathan Lipps]

I like the idea of a general metadata field, sure. Maybe that's more defensible as an official capability than some of the more specific data I'm looking at.

I do think my proposal about specifying information about the client library itself is useful, but at the end of the day users could always opt into using it via a helper library of some kind.

--

Jonathan Lipps

Director of Open Source

Twitter: @jlipps 

GitHub: @jlipps

Sauce Labs | Sauce blog

To unsubscribe from this group and all its topics, send an email to selenium-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/selenium-developers/f9943e9d-2c56-443f-a41b-3c1c99ec7e69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.