On 12/03/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
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.
You can make the producer as simple as you like, as long as you don't
care about both of
a features
b compatibility
you can't have both because TAP was not designed in such a way that
you cannot add a feature to it without either breaking old parser or
turning what used to be for-human fields into for-consumer fields.
> >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.
Well in that case, you're saying there's no need to remain compatible.
If the consumer can't handle it we bail. The problem I have with that
is that every time we increment the version number, everyone has to
upgrade their consumer, even if they don't really need to.
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.
There's as much or as little logic as you like. If you're a producer
and you could only be bothered supporting version 72 then you just say
that and bail or go ahead and ignore any info provided by the
consumer, output version 72 and cause the consumer to bail. What I'm
describing completely contains what you're describing as a subset but
it also offers some flexibility during transitions whereby the
producer can accommodate older consumers without explosions.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
