[TIP] Result protocol / problems being solved (really)

[Jesse Noller]

On Tue, Apr 14, 2009 at 11:44 AM, Victoria G. Laidler <laidler at stsci.edu> wrote:
> Jesse Noller wrote:
>>
>> Yup:
>>
>> 8> This should not require a custom wire format, or parser. It should
>> use something in widespread use (e.g. XML, JSON), it should have
>> cross-language support and be human readable.
>>
>
> I thought about this, but I was trying to separate issues pertaining to the
> result protocol itself (what data it contains, what is the underlyling data
> model) from issues pertaining to the wire format and parsing.
>
> It doesn't make sense to focus on the format before we understand the
> requirements for the data itself. I do agree that language-agnosticism
> probably implies a standard format, and human-readability is a requirement
> for me.

We'll need to agree to disagree: I can't ignore something as
fundamental as making this standard, built on standard technologies. I
think anything which defined some custom syntax, requiring parser
implementations is a quick road to failtown.

>> Other than that, the basic outline is correct. Let me also point out
>> that there is a use case for some people involved that involves
>> parsing results directly from a stream, such as stdout. This means
>> they need the ability to parse the result messages from the stream.
>

This isn't my requirement, but I think it goes like this:

run test in subprocess
capture stdout
parse stdout for result data

The final step implies the ability to separate log information from
result information, ala:

    2009-04-14 14:44:53,501 : INFO     :  connecting to host
    2009-04-14 14:44:53,501 : INFO     :  connected
    2009-04-14 14:44:53,501 : INFO     :  sending job
    result: PASS

The result would need to be parsed by the thing watching stdout.

jesse