Language requirements for server side code in the test framework (was: Review of tests upstreamed by implementors)

On Thursday, March 21, 2013 at 2:11 PM, James Graham wrote:
> We also have the problem that many of the tests simply won't run in
> vendor's systems. Tests that require an extra server to be set up (e.g. 
> websockets tests) are a particular problem, but they are rare. More 
> problematic is that many people can't run tests that depend on Apache+PHP 
> (because they run all the servers on the individual test node and don't 
> have Apache+PHP in that environment). Unless everyone is happy to deploy 
> something as heavyweight as Apache+PHP, we may need to standardise on a 
> diffferent solution for tests that require custom server-side logic. Based 
> on previous discussions, this would likely be a custom Python-based 
> server, with special features for testing (I believe Chrome/WebKit already 
> have something like this?).

So I hop[ing to be able to get rid of Apache/PHP in favor of a much more lightweight system, combined with a convention (a manifest?) to set HTTP headers where necessary.

I was tempted with a node.js based solution, because you know, JavaScript is the language of the Web. But if picking something else guarantees these tests are going to be run by implementors, I'm willing to learn COBOL (just kidding).

Here again, input from all the implementors would be really helpful.

--tobie

Received on Thursday, 21 March 2013 16:18:24 UTC