Re: Self-contained test setup and ports

On Tuesday, September 24, 2013 at 12:04 PM, James Graham wrote:
> 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.

Agreed, I should have written something along the line of "W3C's software license or a compatible license."

That said, given you started  wptserve on W3C's GitHub repository I imagined you were planning to release it under the W3C Software Notice and License. Won't that be the case?
> > 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.

Agreed. However, it seems that limiting the complexity of said server is a worthwhile goal. "Easy to implement on another server" seems like a good measure of that.

--tobie

Received on Tuesday, 24 September 2013 10:19:48 UTC