Hi Barry,
Barry Leiba wrote:
First, as I said on the mic in Québec, thanks, Stephan, for great
reviews of convert and imap-sieve.
+1.
I'll be getting to the latter soon.
Stephan has brought up two main issues (the third is easy, and I've
clarified that for the upcoming version):
1. Do we need a test for what conversions are supported?
2. How do we handle error conditions?
I've tentatively made the following change to section 2 for the second item:
OLD
Implementations ought to defer any actual conversion until the final
resolution of other actions, to avoid doing conversions unnecessarily
in cases where the message is not retained (such as where the
resolution is "discard").
NEW
If a "convert" action cannot be completed -- perhaps because the
conversion failed, or because the requested conversion is not
available -- the message MUST remain unchanged, and the script
processing continues. In particular, no error condition is raised,
and no partial conversions are allowed.
Implementations might defer any actual conversion until the the
results of the conversion are needed for script processing, to avoid
doing conversions unnecessarily. Consider the case wherein a
"convert" action is processed, but a "discard" action results without
the need to actually perform the conversion.
Now, this doesn't take into account Alexey's comment that he'd like to
see a runtime error when conversion fails, so I want to push on this:
What is the use case? Is it more valuable to the use case for a
failed conversion to crash the script, or for it to just continue?
The sense I have is that it should continue (which is why I wrote the
text above).
"I've asked you and you ignored me" behavior doesn't seem right in
Sieve. I don't think any other extension does that.
If we really want to have both (strict conversion and "best effort"
conversion), then maybe we should have a tagged argument to signal that.
If we go with my version, there's an issue of what happens when we're
converting the whole message ("convert" outside a MIME loop) and, say,
three body parts convert OK and one doesn't. Do we consider that a
"partial conversion", and roll back the conversion on the three
successful ones? Or do we only worry about making sure the part that
failed is back to its previous state?
I think I prefer a tagged argument (see above) to control this.
Finally, I had an idea for how we could do the testing, which might
satisfy both issues:
Why not have the "convert" action *also* be a test. Like this:
*** convert with no test ***
require ["mime", "fileinto", "convert"];
if header :mime :anychild :contenttype
"Content-Type" "image/tiff"
{
convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240";
fileinto "INBOX.pics";
}
*** convert with test ***
require ["mime", "fileinto", "convert"];
if header :mime :anychild :contenttype
"Content-Type" "image/tiff"
{
if convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"
{
fileinto "INBOX.pics";
}
}
So it could work either way. In the case where it's used in a test,
it would evaluate TRUE if it ran with no errors -- that is, the
conversion is supported, the parameters are correct, and no
conversions failed (Q: is it also TRUE if no conversions needed to be
done, or is it only TRUE if at least one conversion was done?).
I think "no conversion is needed" is a success case.
If it's used only as an action, with no test, then any failure generates
a runtime error.
What do people think about that? This would be the first action that
could also be used as a test, so think about whether that's good for
the language. I like it, and I think it makes things very simple.
I don't mind that. But I don't think that that should imply any general
correlation between actions and tests for all future extensions we might
design.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve