On Jul 11, 2006, at 7:34 AM, Ian Langworth wrote:
Maybe we don't care. Maybe we can simply add a callback for some
diagnostic_block_analyzer() and, in my own little happy world,
$parser->diagnostic_block_analyzer( sub {
my ($block) = @_;
if ($block =~ m{ \A --- }xs) {
do something with YAML::Load($block);
}
else {
do something else
}
});
If you merge this together with Ovid's proposal, I like it fine. We
have some arbitrary associated chunk of data - format user-defined -
that follows the ok/not ok; if there's a callback supplied to do
something with it, fine; otherwise it's opaque to TAP and we don't
care. Delimiting it visually somehow is probably a good idea.
This is, I think, a place where "stupid is better" wins, The TAP
parser is less complex, which makes it more reasonable to assume that
other languages/platforms will implement it, and the diagnostic info
becomes extremely flexible as to what it contains because it's
essentially unparsed arbitrary data. In an extreme case, it's'
arbitrary binary data: this is the PNG that the program generated. If
you *want* YAML, or MIME headers, or whatever, they're permissible,
as long as the data follows the basic "this is diag data" standard..
A data generator/parser plugin plugs in to the TAP parser: the
generator side encodes diagnostic data in the manner the parser side
will understand. This becomes testable as a separate unitm and allows
anyone to extend TAP in whatever direction they like.
We could go REALLY stupid: the plugin gets a lookin first at each
"item" in the TAP data stream and decides if the TAP parser should
see it at all; then you have no limit whatsoever on the data format,
as long as the plugin can parse it.
--- Joe M.
