- From: Robin Berjon <robin@w3.org>
- Date: Wed, 07 Aug 2013 17:36:17 +0200
- To: James Graham <james@hoppipolla.co.uk>
- CC: public-test-infra@w3.org
On 07/08/2013 17:17 , James Graham wrote:
> However, I'm not sure that I understand the value of that :) Why is it
> easier to create this kind of thing dynamically rather than create it
> statically for a specific test?
I like the idea of creating it dynamically because it makes it easy to
have everything in one place (namely, the test). I can live with
alternatives though.
> Well, it seems that you are writing some kind of script with the
> "actions" thing. If the point is just that you could have a custom
> format for gluing together headers, body, and bits of custom/library
> code, rather than having one python script per test that requires
> dynamic behaviour, that is of course possible, although we should
> consider the barrier to entry of having to learn a custom format vs
> something like
>
> from utils import sendWithDelay
>
> r = Response(200)
> r.addHeader("content-type: text/javascript")
> r.flush()
> sendWithDelay(r, "test.js", [2, 100, 2]) #Wait 2s send 100 bytes of
> file, wait 2s, send rest of file
>
> (totally made up and not based on anything that currently works)
Yeah, but the value of using a DSL (so long as it's a really simple
format) is that we don't at all have to worry about people checking in
code. Presumably once we have this new server we will be phasing out
PHP, and the whole test tree will be served "dumbly". This means that we
can simply publish every single PR on the web without review, etc. It's
much safer.
If it's not dynamically configurable we could have .server files with
the behaviour, the corresponding endpoint being a request for that file.
The content could then be, e.g.:
200 UNICORNS FTW
h Content-Type: text/javascript
wait 2000
b foo()
--
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Wednesday, 7 August 2013 15:36:21 UTC