Geoffrey Young wrote:
However, most perl tests don't care about TAP, they use Test::More and
Test::Harness and happen to exchange data via TAP. If Test::More and
Test::Harness decied to use "YAP" (YAML Anything Protocol? :), then most
applications would probably never notice.
most _perl_ applications would never notice.
IMHO however this overhaul ends up playing out, TAPs current marvel is
that it's wonderfully simple and very forgiving - if the new version
isn't completely back compatible y'all should call it something else,
lest you risk alienating all the non-perl folks who embraced the
protocol because of it's simplicity.
in other words, call it TAP but break current non-perl TAP
implementations and I think you'll wipe out the userbase that some of us
spent a lot of effort trying to win over (and succeeding :)
Indeed, I think we were pretty much clear that under no circumstances
whatsoever would we break full back-compatibility.
The idea of the extra mime-like things was to be able to provide some
relatively simple and cross-language enhancements, so that, for example,
if running tests with a higher verbosity, there could be some feedback
to, say, an editor or a tool about the location of the errors.
This is part of why I dislike YAML for this. Regardless of what the
marketing says, it isn't cross-language for anything more than trivial
use cases, for example objects or !!perl-specific things.
As others have mentioned, the beauty of TAP is it's simplicity and
accessibility. It Just Works across languages with almost no effort at
all, can be done in pure-$your_language easily, and is generally quite
forgiving.
In introducing some form of semi-standard enhancements (such as the
failure diagnostics) I really don't want to lose this.
In using YAML, we're already adding a lot of extra weight, adding
dependencies on C libraries, and tempting people into using the more
ehnanced, non-platform-neutral features.
Lets at least let the YAML spec stop morphing and the language
implementations become stable before we start thinking of making TAP
inherit any baggage from other protocols by adding them as dependencies.
Fair enough a "Layer 1" TAP parser might not care, but why not make it
as equally easy to implement a "Layer 2" parser as well.
Adam K
