On 12/03/07, Andy Armstrong <[EMAIL PROTECTED]> wrote:
On 12 Mar 2007, at 12:15, Fergal Daly wrote:
>> Highest version I'd say. I hope we're not expecting such a complex
>> melange of versions that we need to enumerate the ones we support. If
>> say we're supporting version 10 it's implicit that we also support
>> 1-9.
>
> Are we not anticipate any bad decisions either? Say version 8 was
> horribly broken and no one should ever support it. By saying you don't
> support it the producer should then fall back gracefully to something
> earlier.
If 8 is horribly broken why's the producer trying to produce it in
the first place? How likely is it that we're going to allow a
'horribly broken' TAP grammer into the wild?
> What about the future? Maybe it's 20 years later and I'm writng a TAP
> parser in C#++ and I don't want to have to cater for every version of
> TAP that's ever existed, including the broken ones. So I say
> "12,90-100" the producer can either produce up to date TAP or fall
> back to the very basics.
Madness :)
I don't want every producer written from here forward to have to be
able to negotiate its way through a minefield of supported versions.
But you do want every consumer written from here forward to support
every previous version.
From the producer's point of view the logic should be as simple as
checking that the harness supports our version. If it doesn't emit a
diagnostic and skip.
> If you insist on full backwards compatibility all the way back to the
> start then you future TAP consumers are just going to lie. They'll say
> "100" which is supposed to mean "1-100" but they're just going to hope
> that nothing earlier than 90 ever shows up. If you're lucky they'll
> die when they see a version number they don't support but by
> communicating the reality the user could get the best available.
>
> Plus saying "1-100" is only a tiny bit more difficult than saying
> "100"
It transfers a lot of burden to the producer though. It means that
every producer from now on has parse a discontinuous selection of
version numbers and then do the right thing. The negotiation stage
ends up being more onerous than the actual testing.
my $me = string_to_set($i_support);
my $he = string_to_set($harness_supports);
my $version_to_use = [sort intersect($me, $he)]->[-1];
I don't envision a world where
$i_support = "1,7,34,36-43,78-91"
$harness_supports = "2,8,34,44-57,92-100"
I just think it should be possible in the future to say
$i_support = "78-91"
$harness_supports = "86-100"
In fact, I'd even go so far as to say that an upper and lower version
are probably enough,
F
--
Andy Armstrong, hexten.net