On 21 Aug 2008, at 22:41, chromatic wrote:
I've written a handful of TAP producers and consumers myself, as
well as
software which other people have used in ways I never intended. The
more
complexity you add to a system to reduce the complexity people have
to manage
to use your system as you never intended, the more complexity
everyone has to
manage to use your system as you always intended.
Indeed - but there's a sweet spot somewhere between specifying too
little and specifying too much. It's entirely proper that there should
be a debate about where that sweet spot is - and parsimony should be a
guiding principle - but the value of having inline, per-test metadata
has already been demonstrated.
IMO we don't need a complete serialisation protocol - just somewhere
we can make notes and have them pass unmolested through the harness.
If someone needs arbitrary serialisation they can use a protocol that
makes sense to them and either inline their serialised data as a
Base64 encoded string or have the diagnostic refer to an external
file. The important thing is to open up a conduit through which user
defined data can flow from a test script.
Now, that could just be an opaque block of inline data - but you'd
want that to be delimited in some way so the TAP parser knows how to
step over it. Having to wrap it up as a minimal JSON or YAML is not a
significantly greater burden than, say, MIME multipart encoding it and
using a structured representation increases the chances that common
usage will emerge. Cowpaths to pave.
I favour JSON because it's the simplest solution that fits those
criteria.
--
Andy Armstrong, Hexten
