Eric Hacker wrote:
I think this is a situation where you want a code rather than just
using text. The conciseness eases automatic interpretation and assures
clarity of what was said.
If so, then how many codes? Probably not as many as hundreds.
Best to group codes so that similar codes are easily identified.
Best not to do this using some cool binary or hex code which pushes
the calculation to people rather than the big calculator/space heater.
So lets say that the codes will be 3 digits, so we'll have enough room
to grow for unforseen needs.
Stop. Stop stop stop! Stop right there.
Repeat after me, "We cannot predict how TAP will be used".
We can't. Anything we design now will seem silly and narrow 5, 10, 15 years
from now. TAP, after all, is 20 years old. 20 years ago would be have
considered HTTP status codes? No, they didn't exist. Would we even have
cared about other operating systems? No, it would be Unix exit codes...
just like it is now. If we reduce exit status down to a series of hard
coded 3 digit codes we're erecting an iron crib around the cradle. So
limiting. (999 status codes|64K) will be enough for anyone, right?
Extensibility is the key. This is why I like a YAML or JSON format so much.
We can always add to it.
http://perl-qa.yi.org/index.php/TAP_diagnostic_syntax
1..2
ok 1
ok 2
done (or whatever we wind up using for "end of tests")
---
exit status: 23
wait status: 0
http status: 404
human readable status: Yer screwed.
psychological status: I'm feeling fine, thanks
...
We can leverage any existing status system we want. HTTP status. Exit
status. Throw them all in! Don't find TAP's existing statuses rich enough?
Add your own extension keys! A particular status code not make sense for
your application? Leave it out!
And uses the same mechanism as the TAP diagnostics proposal so little extra
work on the part of the TAP parser is necessary.
And we don't have to plan everything out now and be so very, very, very wrong.
