As described here:
http://forums.openqa.org/thread.jspa?threadID=5124
We should extend getNewBrowserSession (and thereby the DefaultSelenium constructor in all of the clients) to optionally take an additional argument, where you could specify additional options. Here's some stuff I could imagine people wanting to specify, and how they'd specify it:
&1=*iexplore&2=
http://x&3=proxyInjectionMode
(would allow us to get rid of *piiexplore)
&1=*iexplore&2=
http://x&3=multiWindow
(no explicit need for the command-line argument)
&1=*iexplore&2=
http://x&3=proxyInjectionMode,port:4445
(would allow us to open new ports for PI mode at session launch time, allowing us to support multiple sessions in PI mode)
&1=*iexplore&2=
http://x&3=mshta
&1=*firefox&2=
http://x&3=chrome
(MSHTA and Chrome are just modes of using IE and Firefox... why call them different browsers?)
And we can always combine options:
&1=*firefox&2=
http://x&3=chrome,profileTemplate:c:\blah
I'd still want to support the old names/modes for backwards compatibility, but this seems like a good idea to me.
Oh, and, while we're at it, maybe get rid of the "*"?
(The star is really there for historical reasons. If you omitted the star, we used to assume you meant to use a custom browser, but we quickly learned that was confusing ["firefox" means run firefox from the path directly without modifying it, whereas "*firefox" means use logic to calculate the firefox location and modify its profile heavily]. It was clearly the right decision to demand that you call it "custom" if you wanted to use a custom browser.)
If we did remove the star, we might even want to do this:
&1=firefox&2=
http://x&3=executable:c:\blah\firefox.exe
(http://selenium-grid.openqa.org/how_it_works.html#requesting-a-specific-environment)
On the other end I am not especially fond of the proposed mechanism as the parsing of these options requires knowing about them ahead of time. If a user wants to define a custom defined environment "IE on Windows XP SP2 - Opteron" parsing '&1=*ie&2=IE%20on%20Windows%20XP%20SP2 is impractical
Having the opportunity to name the options and have Selenium RC ignore them if they are not recognized seems a lot more extensible: Ideally
&1=ie&env=E%20on%20Windows%20XP%20SP2
I realize that this is not consistent with current way of handling Selenese with rely on sole order to parse the parameters. A degraded form could be:
1=ie&2=env:ie%20on%20windows%20xp%20sp2
What do you think?