[tap-l] User Supplied YAML Diagnostic Keys: Descriptive Version
David E. Wheeler
david at kineticode.com
Thu Apr 17 06:57:21 UTC 2008
On Apr 13, 2008, at 15:58, chromatic wrote:
> The problem with an infinitely expandable protocol that tries to do
> 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
> 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
> in the wild? How about HTTP headers? Maybe you don't have to care
> 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
> didn't completely suck.
In principal I completely agree with you, chromatic (that is, I agree
with the principal you espouse here; my agreement is not purely
theoretical ;-)). But how does that work in practice? Specifically
with regard to YAML diagnostic keys in TAP? What do you suggest? Maybe
just reserving the keys we know we need now, and then adding more
later as we need them, even though doing so might conflict with other
folks using such keys?
I just want to know how we might put what you've said into practice.
More information about the tap-l