On Tue, Feb 07, 2006 at 03:11:44PM +0200, Alexandros Vellis wrote:
I suggest that allowed modifications MUST or at least SHOULD be
documented.
Usage: valid_notif_method <notification-uris: string-list>
Of course that is real easy to implement, but it is also real ugly.
There is nothing I know of else in Sieve that checks certain options
of actions for validity. I still suggest a generic extension for
exception handling.
I don't know about generic exception handling, but wouldn't it make more
sense, in this particular case, that the available notifications are
present in the capabilities of the Sieve server?
I am not sure if you talk about managesieve or a new capability test,
but anyway:
If the method consists of variables, you can not test the method when
installing a script. Although I think "if you write code that shoots
in your foot, then suffer", I must admit that a script really shouldn't
cause an error just because of a notification, and simply ignoring all
notification errors is awkward, too.
So we do need some way to deal with errors, both semantic and runtime
errors. The "valid_notif_method" addresses semantic errors and we
decided that "notify" should never cause runtime errors.
In a way, notifications are remotely similar to "fileinto + redirect".
We have no facility to check a redirect address, and I am not asking
for valid_redirect_recipient, although it would be easy to implement.
I am asking for a generic way to solve the problem.
try {
notify "sms:NaN";
}
catch {
}
Yes, that's a can of worms and possibly not a good idea at all, but I
see a need for _some_ generic solution and that's all I can think of
right now.
Good idea. I think that the current plan is a bit awkward. The Cyrus
implementation uses the :options field to define the email address:
notify :method "mailto" :options "foo(_at_)example(_dot_)org"
Well, the notify draft changed a lot (IMHO, for the better) and
was probably never widely employed. I don't expect agreement upon
implementations a few days after the latest draft. :-)
Michael