[tap-l] Nested TAP

[Andy Armstrong]

On 14 Apr 2008, at 21:23, Ovid wrote:
> By requiring a summary line, we *gain* the simplicity of always having
> the top level TAP stream parseable without forcing the consumer to
> introduce complications necessary to parse nested TAP.  With my
> solution, determining if the top level core TAP stream passed or  
> failed
> is trivial and *that* I think is what we should be focusing on.


OK, that's probably another axis along which we can disagree :)

I favour keeping the overall complexity down - but to the extent that  
we have features that are tricky to implement I'd like that complexity  
to be in the consumer. In my view the utility of TAP is dependent more  
on the ease of writing producers than consumers. Users of other  
languages will derive more benefit from being able to write a producer  
in their native language.

For me one of the crucial advantages of not requiring a summary result  
is that facilitates assembling TAP streams from multiple producers  
without any particular co-operation (either shared state or parser/ 
aggregator) between those producers. In the case of e.g. an embedded  
system that kind of simplicity seems to me to be a huge win. I can't  
imagine a use case that has me writing a TAP consumer to operate in  
such a constrained environment.

Requiring people to write a complex TAP producer in, e.g. PIC  
assembler seems less appealing than requiring them to use a pre- 
existing TAP consumer written in Perl. In general, in cases where  
there is a disparity between the platform running the producer and the  
platform running the consumer, the producer will be operating in a the  
less salubrious environment.

-- 
Andy Armstrong, Hexten