* Fergal Daly <[EMAIL PROTECTED]> [2007-03-12 00:45]: > This brings up something else. Future harnesses should probably > set > > I_UNDERSTAND_TAP_VERSIONS="1,5,8,10-22" > > so we know what we can output. If that's not set then we need > to stick to plainest TAP.
No, I don’t think so. How do you set environment variables when the producer lives at the other end of an HTTP connection? How do you set environment variables when you’ve pipe the producer’s output into a textfile and now you’re run a consumer against that, two weeks later? Requiring bidirectional communication will greatly reduce the number of scenarios in which TAP can be used easily. And if you require coupling between producer and consumer to the point of needing in- or inter-process communication of some sort, then what is the advantage of having a protocol vs an API like JUnit? For all this, I’m unconvinced of any real gains. TAP is supposed to be so simple that you can Test Anything with it because *anything* could be wired up to produce TAP. That should mean TAP will not get significantly more complex than it currently is; I’ll be dismayed if I find that TAP in 2020 looks much different from TAP today. It should also mean that even if consumers end up having to support multiple versions of TAP, it won’t be too difficult. And lastly it should mean that at any point there will be many fewer consumer implementations than producer implementations. So it makes sense to take the unproven risk of some moderate future burden on consumers in exchange for retaining the advantages of a protocol being a protocol and not an API. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
