[tap-l] Nested TAP

[Andy Armstrong]

On 14 Apr 2008, at 20:20, Ovid wrote:
> If the TAP consumer (Test::Harness in our case) doesn't say that it
> understands TAP v13, the producer has *no* way of downgrading the  
> above
> TAP and would be forced to abort -- unless it had a minimal parser
> (like my 40 line example which can be made even shorter).  Thus, tests
> which *should* pass will now fail.  That violates the entire spirit of
> TAP.


I'm lost now :)

Am I right in thinking that the principal differences between the two  
approaches can be summarised thusly?

Your approach: generated TAP is automatically backwards compatible,  
producer needs a minimal parser or additional logic to keep track of  
summary results, producer doesn't need to know the TAP version  
supported by consumer.

My approach: nested TAP isn't b/c, simpleminded producers (no parser),  
producer can downgrade iff it knows the TAP version supported by  
consumer.

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

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 :)

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.

-- 
Andy Armstrong, Hexten