- From: James Graham <james@hoppipolla.co.uk>
- Date: Tue, 24 Sep 2013 11:04:18 +0100
- To: Tobie Langel <tobie@w3.org>, "Wang, Jing J" <jing.j.wang@intel.com>
- CC: "public-test-infra@w3.org" <public-test-infra@w3.org>
On 24/09/13 09:09, Tobie Langel wrote: > On Tuesday, September 24, 2013 at 2:19 AM, Wang, Jing J wrote: >>>> I don't know exactly what you mean. However, let me try to explain. >>>> >>>> The server reserves the "pipe" query parameter for its own use. The value of this parameter specifies, in effect, a server internal function that the response will be passed through. In this case I am suggesting that the "config" function be defined as something like: >>>> >>>> def config(request, response): >>>> response.content = response.content % config_dict >>>> >>>> This means that the replacement will be transparent to the browser; it will just see static files with the correct values for each parameter in. >> >> Thanks James for explanation. So, server helps do the transparent replacement, but my concern is it make TC very dependent on specific Web server. > I think that's an acceptable tradeoff to make for a given subset of tests, granted: > > 1) the server is available under W3C's software license, This seems like a made-up requirement. The server-side components we use today are a mixture of Apache, BSD and PHP licensed, so clearly there is a large class of non-W3C licenses that are acceptable to us. > 2) it's sufficiently portable, and > 3) the transformation is simple enough that it would be easy to implement as middleware on top of a different server. We were always dependent on a specific set of servers. Previously these were apache + mod_php, pywebsocket, mozhttpd, and Jetty. The plan for the future is to change this to wptserve + pywebsocket, which, in the case of the apache -> wptserve transition, has a number of advantages including a featureset specifically tailored for our use case, better compatibility with vendor automation setups, and greater freedom to implement modifications. Testing relies heavily on the ability to generate very precise inputs from the server and attaning the same level of precision across a range of servers seems very difficult. It also seems rather pointless. I don't think anyone has yet made a case that running on multiple servers is needed *at all*, let alone that it is worth the substantial costs.
Received on Tuesday, 24 September 2013 10:04:44 UTC