Hi Fergal, * Fergal Daly <[EMAIL PROTECTED]> [2007-03-12 18:00]: > On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: > >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.
So I have to make up an ad-hoc way to communicate with every possible producer? > >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. Why? And why should I have to write code that tries to divine what TAP version to produce and then conditionally produce some version of TAP other than the highest I know, when the code emitting TAP is machine code running on a microcontroller? Isn’t it more reasonable to expect the consumer to be complex, rather than the producer? I’d rather reluctantly miss any useful features from newer TAP versions and just produce plain old TAP, regardless of what’s at the the other end of the wire, than having to go through all those gyrations. > >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. No, I’m saying it’s reasonable to expect future consumers to support all versions of TAP ever. In fact I’m saying it’s reasonable to offload almost all complexity to the consumer. The only thing we need is for producers to be able to declare what version their output conforms to. If the consumer can’t cope with that version, it can just tell the user and bail out. Making “either the consumer talks to the producer and the producer has to implement some complex logic, or the producer sticks to the plainest TAP possible” a requirement would just lead to most ad-hoc implementations of producers being forever stuck with producing the plainest TAP possible. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
