ietf-mta-filters
[Top] [All Lists]

Re: ihave and server upgrades

2009-01-21 11:32:39


I implemented ihave. It was easy. I ran into a strange point, though.

     require "ihave";
     if ihave "foo" {
         foo :dwimfactor 4;
     }

There are three cases.

1. Server supports foo at upload. Upload results in a managesieve error
such as "NO Maximum DWIM factor is 3". Fine.

2. Server doesn't support foo, period. Upload succeeds, execution
succeeds. Fine.

3. Server doesn't support foo at upload, but is later upgraded to a new
version which supports foo. Now the script fails when run. Not so fine.
It riles me that one thing can break because another is upgraded.

I don't suppose there's anything to do about it, but it still riles me.

Me too. In fact I had to deal with exactly this case recently because I just
improved checking of tagged arguments in our implementation. And I have to
agree there's nothing to be done about it.

A similar case I've seen come up many times over the years  is that of
scripting languages that allow abbreviations. So you write something like this
in a script:

   $ rec foo

where rec is an abbreviation for "recover". This works because there's no other
command that begins with "rec". Then the system is upgraded, and a new "recall"
command is added. And the script breaks because now "rec" is ambiguous. (And
yes, this example really happened.)

I suppose another way to think of it is as an untested code path which, when
finally activated, is found to contain a bug. But thqt doesn't provide much
solace either.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>