[tap-l] Nested TAP

Ovid publiustemp-tapx at yahoo.com
Mon Apr 14 21:23:04 UTC 2008


--- Michael Peters <mpeters at plusthree.com> wrote:

> 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.

That would depend on whether or not those are good or bad decisions. 
Heck, as were were debating various ideas on Oslo and had tentatively
agreed on breaking backwards compatibility, I realized that there
wasn't much stopping us from going whole hog and dropping TAP
altogether in favor of YAML.

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. 
Someone could then write a minimal producer/consumer and add features
as needed rather than going down the more difficult route of requiring
them to parse arbitrarily nested TAP.  Thus, someone who's parser can
only handle basic core TAP could handle the newer versions.

I would agree to break backwards compatibility if and only if we can
reasonably demonstrate that we're solving more problems than we're
introducing.  So far I don't see that, but I'm willing to be convinced
since I acknowledge that we have issues with nested TAP.

Perhaps we should step back and ask ourselves what problems we're
trying to solve with nested TAP and ask if there are other approaches?

Cheers,
Ovid

--
Buy the book  - http://www.oreilly.com/catalog/perlhks/
Perl and CGI  - http://users.easystreet.com/ovid/cgi_course/
Personal blog - http://publius-ovidius.livejournal.com/
Tech blog     - http://use.perl.org/~Ovid/journal/


More information about the tap-l mailing list