On Tue, 2004-10-26 at 18:37 -0400, Mark E. Mallett wrote:
On Tue, Oct 26, 2004 at 11:04:55PM +0200, Kjetil Torgrim Homme wrote:
if the feature is integrated in the language, it can't be disabled.
Oh, I see what you were getting at- native variables implies more
complex scripts (or at least scripts that have a higher resource load)
which may be bad from a system administrator's perspective, vs a
variables extension which an administrator could choose not to enable.
But resource issues are resource issues, and language issues are language
issues; they ought to be addressed on their own.
from a practical viewpoint, it's not only a resource issue, it's also a
security issue -- a complex language will have a complex implementation,
with greater potential for security flaws. a minimal Sieve
implementation can be written in few lines of code, meaning it can
easily be scrutinised by a security conscious administrator.
I think if you disagree with typed variables, we are just going to
disagree, especially as I concede that you can apply operations to
string variables that interpret them in different ways- although
that's not my preference.
do you want strong typing? in most script languages the type is
implicitly cast to string or integer as needed. since any type can be
expressed as a string, or as a number, it doesn't really matter what
happens behind the curtains, unless you wish to enforce type "safety".
Structures are useful for anything where you have tuples that you
want to apply general processing to. Off the top of my head, you
might have a set for each mailing list you are on:
- list name (inside List-Id, say);
- folder to file mail into;
- an optional prefix to add to the header;
- whether to add a "Mail-Followup-To" header for your local use;
- what IMAP flags to set
etc.
You can consult an array of such structures and apply processing
generally. You can even load the array from a file that's separate from
your script. Or you can do all that stuff inline, one at a time.
exactly. what's the difference between successive tests on List-Id and
storing the values in a lookup array? the representation is different,
but the information is the same. this is static, you (or your e-mail
client) could even generate the Sieve script from a different style
configuration.
I have the attitude that if you provide things like typed variables,
structures, and fundamental language features, people will use them, and
you can't always predict the things that people will do with them. In
my original note I opined that in an eventual implementation of native
variables, only one data type might be provided (and of course I had
strings in mind), but that design should not prevent the eventual
addition of more types. (I didn't say it quite that way, but it was
roughly the same.)
this thread is the closest we've been a discussion of 3028bis. why
don't you post what changes you think we need to the basic grammar to
allow such a future of Sieve?
none of the competing e-mail filtering languages I know (procmail, MH,
Exim-filter) are significantly more expressive than Sieve. I think that
indicates there is no great demand for it.
Really... seems to me that procmail is the poster child for demand for
extra features. Most useful procmail scripts do all kinds of piping to
external programs to do things that can't be done inside procmail.
your view of "useful" is different from mine :-). I had totally missed
the "var=|program" syntax to set variables based on the message. I
haven't felt a need for the feature, though.
Maildrop is a popular delivery language that seems to illustrate
peoples' desire for more expressive scripting languages.
maildropex(7) includes code for implementing vacation, absolutely
horrific if you ask me. a friend also wrote YAMPLE which is really Perl
used as a filter language. fine for a home system, but neither is
suitable for a big e-mail system, IMHO.
--
Kjetil T.