[tap-l] User Supplied YAML Diagnostic Keys: Descriptive Version

[chromatic]

On Sunday 13 April 2008 14:58:33 Michael G Schwern wrote:

> chromatic wrote:

> > On Sunday 13 April 2008 10:41:04 Michael G Schwern wrote:

> >> Remember, the producer and the displayer of the non-reserved keys are
> >> both under local user control.  They choose the custom keys and they
> >> choose what they need and can handle.

> > That sort of eliminates the upgrading problem, doesn't it?

> How's that?

Any organization with custom code on both sides of the producer/consumer 
pipeline has the option of upgrading Test::Builder or TAP::Harness, modifying 
their local modules, or neither.  This is the same choice everyone always has 
when maintaining local forks.  If you don't get your code in upstream, you 
get to maintain it yourself across releases.

If you want to pave cow paths, you're going to have to watch where cows go.  
Shunting all of the cows into a pasture you'll never see doesn't really help.  
Put some pressure on downstream to get their customizations in the next 
revision of TAP (there's a reason TAP has version numbers).

The problem with an infinitely expandable protocol that tries to do everything 
is that it's infinitely expandable and tries to do everything.  Might be nice 
to rein that in a little bit more.  Or don't, and instead make it trivial to 
add ad-hoc keys willy-nilly without planning or communication or consistency, 
and you'll end up with the protocol equivalent of spaghetti.  Anyone care to 
guess how many X-* headers there are in all of the SMTP clients and servers 
in the wild?  How about HTTP headers?  Maybe you don't have to care about 
them when they're in the spec, but at some point, someone has to write 
software to produce and consume them.  It would be nice if that process 
didn't completely suck.

-- c