On Apr 13, 2008, at 15:58, chromatic wrote:
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.
Hey chromatic,
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.
Thanks,
David
