[tap-l] Nested TAP

[Aristotle Pagaltzis]

* Ovid <publiustemp-tapx at yahoo.com> [2008-04-14 21:25]:
> The problem with the current ideas for breaking backwards
> compatibility is there's no way for the TAP producer to
> downgrade.

That rings alarm bells for me. I don’t think we can *assume* any
way for the consumer and producer to communicate at the time of
TAP production. The two ends can be completely decoupled in space
and time; that is (implict in) the point of TAP.

> Consider:
> 
>   TAP version 13
>   ok 1 - foo
>     begin 2 - nested
>     1..2
>     ok 1 - bar
>     not ok 2 - fribble
>     end 2 - nested
>   not ok 3 - fook
> 
> 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.

Am I correct in thinking that you can translate this to a back-
compatible TAP stream merely by inserting an unindented
`not ok 2` line before the `begin 2` line?

If so, then it is inevitable that someone will have to parse the
nested TAP, and it’s merely a question of which end that will be.

If that is the case, why are we trying to dictate the side on
which this should happen?

I would argue that instead of pinning the duty on either end, we
should merely describe how TAP v13 can be downgraded to TAP v12
and leave it up to individual users of TAP where they want to
shift that complexity. If push comes to shove, they can write an
intermediate pipeline step that takes v13 TAP and downgrades it
in the manner we have described in the spec before sending it to
their v12 consumer.

In fact, we should probably make v13 allow both the presence and
absence of the back-compat shim line. That way, people can write
v13 producers now that work with v12 consumers now, but those who
have upgraded their entire infrastructure can shed that crutch.


* Michael Peters <mpeters at plusthree.com> [2008-04-14 22:10]:
> 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.

++


* Andy Armstrong <andy at hexten.net> [2008-04-14 23:15]:
> 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.

Fully agreed. One thing we know is that even as we’re working to
remove the one-producer-one-consumer situation, we will *always*
have more producers than consumers.

It is important to avoid upgrade-the-world scenarios, but it is
equally important to be able to write completely dumb producers.
I think both of these goals need to be kept in mind for every
future version of TAP.

For nested TAP I think we can achieve this in the way I described
above, by allowing consumers to be burdened, but making the
burden optional such that it is limited to a transition phase.
Those who write producers in PIC assembly can then choose to take
the hit of having to upgrade their consumers, which is clearly
the cheaper option for them.


Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>