On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
* 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?
It's not a HTTP connection it's a HTTP request an important
distinction because a request means that it is initiated by the side
that will end up processing it which can therefore pass information as
part of the request.
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?
Nope, without communication you simply fall back to emitting plain old
TAP. You might lose functionality but it's functionality that was
probably only important to a developer. If you're a user installing
the module then it either passes all tests or it doesn't. If you want
to run the tests the way the developer intended (for example to
produce a helpful bug report) you can go upgrade your stuff.
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.
Burden on consumers? There's no burden on consumers because what you
are saying is that TAP will forever be compatible with today's TAP. In
that world, consumers have it easy, it's the producers who have to
jump through hoops trying to find ways to add functionality without
upsetting 20 year old parsers.
F
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
