On Wed, 2009-01-21 at 10:46 -0500, Jeffrey Hutzelman wrote:
--On Wednesday, January 21, 2009 07:37:46 AM -0800 Aaron Stone
<aaron(_at_)serendipity(_dot_)cx> wrote:
On Wed, 2009-01-21 at 09:57 -0500, Cyrus Daboo wrote:
Hi Kjetil,
--On January 21, 2009 2:37:50 PM +0100 Kjetil Torgrim Homme
<kjetilho(_at_)ifi(_dot_)uio(_dot_)no> wrote:
I don't suppose there's anything to do about it, but it still riles
me.
good point. one solution is to remove dead code (e.g, like Cyrus'
"byte 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.
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.
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.
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