Good points there... Here's my two cents (and a bit). 0) Not explicitly highlighted, Selenium Core generates an XML file with a full description of its API; this is enough information to generate copious javadoc, ndoc, rdoc, pydoc, or POD perldoc. We should use it for something perl-ish, one way or another.
1) It's worth noting that the other drivers (java, c#, python, ruby) *do* have build code. For python/ruby, there's just enough build code to run XSLT to generate code, run some tests, and generate doc, but the c# code requires running it through csc and the java code is compiled by Maven. A makefile would therefore not be out of place. 2) As clever as the AUTOLOAD code is, it can be very opaque to end users. Since the AUTOLOAD code has no explicit definition of "click" (for example), users can't grep through the code for its implementation, and they have to consult the Selenium website for reference documentation. While we could use the Core XML to merely generate POD documentation, at that point we're really 90% of the way towards generating all of the Perl code, which I would probably prefer. 3) It's never been clear to me what to do with code that is partly Perl and partly something else. CPAN is full of pure Perl (or Perl + C) projects, but Selenium will always be a multi-lingual project (for the browser-side JavaScript alone, if not also the Java server). What do people normally do with that kind of project? 4) I'm happy to volunteer to maintain a *thin* Perl driver that does not include its own back-end code. Such a driver should be no longer and no more complex than the Python, Ruby, Java or C# drivers, and can/should include automatically generated code/doc. If the project is bigger than that, though, someone else will need to do it. -Dan
