[TIP] Result protocol

[Jesse Noller]

On Sat, Apr 11, 2009 at 11:09 PM, Douglas Philips <dgou at mac.com> wrote:
> Wow, take one afternoon off and what I've missed!
> I'm not going to try to catch up, too much has moved on, so I'm just
> going to jump in here:
>
> On 2009 Apr 11, at 10:52 PM, Jesse Noller wrote:
>> Yes, no matter the output, the things above that in the stack need to
>> be able to derive something from it, which means walking the data/etc.
>> But why deal with yet another parser when there's plenty out there for
>> free? They're largely defensive against malformed data (or semi
>> tolerant) as well.
>
> I have to say, that is precisely why I like Pandokia's format.
> Simple, human readable, -text-, since, after all, test results are
> destined for human consumption.
>
> I've noticed that this discussion seems to be oscillating between
> a: Keep it simple and human readable and text.
> b: Make it arbitrarily general, capable of binary blob transport, etc...
>
> I'm going to put a stake in the ground and suggest:
> Pick 'a'. We're talking about test results and associated textual meta-
> data.
> If you want 'b', define a protocol that wraps/subsumes 'a' rather than
> extends it.
>
>

Yeah, you missed the part where I corrected your assumption I was
talking about B. I don't want binary blobs IN the reports. I also
don't want a custom parser. Ergo, something human readable ala
JSON/YAML.

Flat text/custom parsing sucks. That's my steak on the ground.

>
> ?? GPL is untouchable? I'm curious what your licensing requirements
> are (I might have missed it in the avalance of emails today? :) )
>

For reasons I won't go into, I don't contribute or deal with GPL code.
I will consume it, and be thankful for it, but I won't use it in my
projects. BSD/MIT/Apache. *shrug* my requirements need not apply to
others.

> See above ('a' and 'b'). As this discussion has gone back and forth,
> I'm pretty well convinced that this is above the 80% threshold.

No. I agree: human readable, extensible. Not aiming to include
anything but text in the files/results, but I refuse to budge on the
point of custom parsers. Again, it's me, not you. We have plenty of
easy-to-serialize, easy to read things out there, with multiple
language support already.

I've already been down the route of custom parsing from a magic syntax
I cooked up which I thought would be simple enough to do "everything"
- and I consider it like I do writing custom "test languages" and
DSLs: not worth the headache.

jesse