Re: [tap] "ok 1 description" vs "ok 1 - description"

[Steffen Schwigon <[e-mail]>]

Hi!

[Don't worry. Just explanations follow, I will agree you in the end.]

[And I write some words bold, just for better readability, not
shouting.]


Michael G Schwern <[e-mail]> writes:
> Steffen Schwigon wrote:
>> Hm, not neccessarily as I provide an API to evaluate the archived
>> TAP by descriptions. It would just work as long as I control the
>> evaluation environment, which I still do at the moment.
>
> Are you going to be passing interpretations of the descriptions back
> and forth between different implementations?

No, not back and forth, but through 3 independent layers:

 1. producer,
 2. abstract API (using TAP::Parser),
 3. query tools (using the API).

I am level 2, level 1 and 3 just use me.


> That is, when does the interpretation of the description matter to
> anything but a single implementation?

It's about beeing *the description is the interface*.

I do *not* provide TAP::Parser directly but provide an abstract API
which can search for a description and let others write third-party
tools which depend on what they themself pushed in the *beginning* of
the process queue and let them also query results at the *end* of the
queue about their own descriptions.

Then they depend on my middle layer (TAP::Parser) beeing *constant*
in these descriptions throughout the years.

Because if today they query results for "- DESCRIPTION" (because they
created it with dash) and TAP::Parser changes later then they will not
find the results because it's now just "DESCRIPTION".

Changing this behaviour was what I was worrying about in the beginning
of the discussion.


>>> What are you doing with them?
>> 
>> Archiving to track history of testruns and recognize result
>> changes. Probably similar to Smolder, I think, maybe more
>> finegrained. Therefore I care for single tests and their
>> descriptions.
>
> Looking at it another way, the WORST thing that happens with mixing
> a legacy producer which isn't aware of the dash with a post-spec,
> dash stripping parser is that the description might get interpreted
> wrong and you can't associate a description with it's historical
> results

Near the truth. Indeed. It's about matching "historical results", yes.

My users own the "entry" and the "exit" of the queue. My task is to
provide the stable "middle layer".


> (though that would indicate that the test started using a different
> producer, which stretching this scenario even further).

Hm, not exactly. My problem is about starting to use a different
*middle layer* in an environment with different producers at the same
time.


> Since using the description as a unique test ID is already a
> heuristic (something that was discussed in some depth at Oslo) your
> system must already be resistant to this problem.

Fully correct. But *that* (i.e., create useful descriptions they can
later query again) is *their* responsibility, because they own "entry"
and "exit".

My layer is the middle one, therefore *my* task is about the stability
of the description.


> Finally, if the parser always strips the optional dash it should always come
> out the same whether the producer uses a leading dash or not

*EXACTLY*. That's why in the mean time I *FULLY AGREE* with you.

(I hope you made it through here. :-)

Because that would make my middle layer independent from the different
provider styles by "stabilising" or "harmonizing" the descriptions in
a defined way.

And all my reports from different producers would always be queryable
in the same way, independent from their "dash style".


> EXCEPT for one contrived case.  When a description deliberately is
> supposed to have a leading " -".  I can only think of a fairly
> contrived example, but if you wanted to output, say, Morse code

I *really* had to lough here. :-)


> Is this edge case important?

Of course. Supporting Morse descriptions is a strong MUST HAVE. :-)
No, not really.


> It seems one simple way to allay your fears is to simply go through
> your historical TAP archives and look for instances where a
> description starts with "- ".

I don't need to. For the above "stabilizing" effect I'm willing to fix
the third party tools around me to just query without dashes, once
that dash is optional. And in the mean time I need to be able to fuzzy
search anyway somehow.

Am I strange? Or is it my approach? I should probably print out this
mail and present it on the next yapc::europe. :-)


Kind regards,
Steffen 
-- 
Steffen Schwigon <[e-mail]>
Dresden Perl Mongers <http://dresden-pm.org/>
German Perl-Workshop 2009 <http://www.perl-workshop.de/en/2009>