Subject: ihave and server upgrades

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Jan 2009 13:54:52 +0100

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.

Arnt

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 21 Jan 2009 14:37:50 +0100

> 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.
> 

good point.  one solution is to remove dead code (e.g, like Cyrus' "byte
compile") from the script at upload time.

-- 
regards,
Kjetil T.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Jan 2009 09:57:59 -0500

> compile") from the script at upload time.

Or when you upgrade a server, the server ought to have a "sieve lint" tool 
that can scan all existing scripts (as would happen during an upload a 
script) and report problems that the admin can take action on.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Jan 2009 16:00:50 +0100

> Or when you upgrade a server, the server ought to have a "sieve lint" 
> tool that can scan all existing scripts (as would happen during an 
> upload a script) and report problems that the admin can take action 
> on.

Personally I like that better. Or at least so the admin will know what's 
broken (ie. that it's not the upgraded server).

Arnt

---

From: Aaron Stone <[email-masked]>
Date: Wed, 21 Jan 2009 07:37:46 -0800

> Hi Kjetil,

I don't think that's realistic -- some extensions can be implemented
entirely by the interpreter, with no need for any other part of the mail
system to get involved. So if the interpreter (a shared library, let's
say) is upgraded, there's no good way to inform the mail system what
changed and to run a lint process.

Aaron

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Jan 2009 10:44:59 -0500

--On January 21, 2009 7:37:46 AM -0800 Aaron Stone <[email-masked]> 
wrote:

>> upload a  script) and report problems that the admin can take action on.
>

Well the system administrator better read the release notes and those 
better say that the interpreter was changed significantly and that all 
existing scripts should be checked. An admin blindly doing upgrades without 
checking release notes/instructions is asking for trouble...

-- 
Cyrus Daboo

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jan 2009 10:46:20 -0500

<[email-masked]> wrote:

>
> On Wed, 2009-01-21 at 09:57 -0500, Cyrus Daboo wrote:
>> Hi Kjetil,
>>
>> > good point.  one solution is to remove dead code (e.g, like Cyrus'
>> > "byte compile") from the script at upload time.
>>

I think you're misinterpreting Cyrus's point.  The idea is not that the 
mail system somehow automagically looks for problems and starts notifying 
people about them.  The idea is that there is a tool the admin can run to 
look for problems in a script.  Depending on the implementation model, this 
might come with the interpreter or with the mail server.

---

From: Ned Freed <[email-masked]>
Date: Wed, 21 Jan 2009 08:12:32 -0800 (PST)

> 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

---

From: Aaron Stone <[email-masked]>
Date: Wed, 21 Jan 2009 08:49:19 -0800

> --On Wednesday, January 21, 2009 07:37:46 AM -0800 Aaron Stone 

Ah, the existence of such a tool is certainly reasonable (as I note to
myself to write one for my mail server). And to Cyrus' reply on reading
release notes, yes, that's very reasonable, too.

Failing both, though, I'd handle it just like any other unexpected
runtime failure of a script -- drop a note in the user's Inbox
indicating that their Sieve script isn't working and all mail will be
delivered to their Inbox for now.

Aaron

---

From: Paul Russell <[email-masked]>
Date: Wed, 21 Jan 2009 16:50:49 -0500

> yes, this example really happened.)

Gosh, I can't remember the last time I was bitten by that kind of sloppy coding,
but it was probably shortly after I started programming on an IBM 370-148, back
when dinosaurs still roamed the earth.

-- 
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame
[email-masked]

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 22 Jan 2009 15:35:38 +0100

> 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.

Heh. Improve it to handle this.

Consider the extensions random, which provides a test which returns true 
or false randomly, and well, which provides a tag for fileinto.

require [ "random", "ihave" ];
if anyof( random, not ihave "well" ) {
     fileinto :well "a";
} elsif random {
     fileinto :well "b";
} else {
     fileinto :well "c";
}

Two of those three blocks are bad. Which ones? I have NOT improved my 
code to the point of handling this.

> scripting languages that allow abbreviations. So you write something 
> like this in a script:
>
>    $ rec foo

(REXX?)

> 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.

No... I hate it when person x changing something here breaks something 
for person y over there. Too great potential for sending either/both of 
them chasing wild geese.

Arnt