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
