[tap-l] Nested TAP

[Michael Peters]

Andy Armstrong wrote:

> I like the idea of not breaking backwards compatibility /now/ - but I  
> don't like the idea of living with backwards compatibility baggage  
> forever.

I'll go one step further and say if we want to have TAP break out into the
non-Perl world we should shed as much old baggage as we can now so we can move
forward. I agree that always having a lock-step upgrade between the producer and
consumer is a bad idea. But doing it this once, this early on in the life of
TAP*, to add a radical necessary change to the protocol would be a good use-case
IMO.

Try explaining to Java folks, or the IETF that we're making some decisions for a
language-agnostic protocol base on decisions that Perl made 20 years ago. That
would turn me off right then and there.

> Both seem like reasonably approaches. I think one's preference would  
> depend on the relative values attached to backwards compatibility and  
> future simplicity. I think future simplicity wins in the long tail :)

Here here!

> Another point in favour of your suggestion: there's no need for a  
> producer to contain a parser unless it aggregates tests. If it's just  
> generating nested TAP it can probably generate the summary result  
> based on its own bookkeeping.

Not really. For instance if there are multiple threads producing TAP the parent
would have to communicate to the child what test number it is before it can
produce the summary line.

* - I know it's been around for 20+ years, but not as a language-agnostic
protocol it hasn't.

-- 
Michael Peters
Plus Three, LP