Tim Legant <[EMAIL PROTECTED]> writes:
> Gre7g Luterman <[EMAIL PROTECTED]> writes:
>
>> Could the filters be done in Python code instead of a proprietary
>> script syntax?
[...]
>> I think it would be neat to write:
>>
>> if from-file("~/.tmda/lists/work"):
>> deliver(dir="~/Maildir-work/")
>>
>> instead of:
>>
>> from-file ~/.tmda/lists/work deliver=~/Maildir-work/
>
> It would be neat for you and me and other Python coders, but
> would be, I think, noticeably more difficult for non-coders.
If the filtering language required constructs more complicated than
an if-then-else, I would agree. For basic statements though,
Python is no more complex than FilterParser.
> Python, as clean as it is, still has certain syntactic elements
> that don't really make sense to non-coders, such as indentation
> and trailing colons.
There's a certain format presented in the filter documentation as
it is today, why couldn't it be translated into some rudimentary
Python requirements. Even a ``non-coder'' could understand, ``all
the lines after the colon need to line up, and when you're done
with that group of lines, de-indent.''
We could even refer them to the first couple sections of the Python
tutorial. It might take them thirty minutes to read.
> The filter language today doesn't have conditionals, or nested
> block structures, etc. and seems to be relatively easy for
> non-coders to pick up.
Just because Python has those features doesn't mean they have to be
used. Someone might not understand the ``tag'' rule in
FilterParser (it's probably the most complex thing there), so what
do they do? They don't use it. If they can live with
from [EMAIL PROTECTED] ok
from [EMAIL PROTECTED] drop
They could also live with
if sender == '[EMAIL PROTECTED]': TMDA.pass()
if sender == '[EMAIL PROTECTED]': TMDA.drop()
It's slightly more confusing, but nothing that can't be understood
after reading config-filter.html. It has the added benefit of
cultivating a useful skill (albeit rudimentary).
Using Python source for .tmda/config was brilliant. It's simple
enough for the guy who just wants to set a couple of variables, and
as complex as someone who knows what they're doing wants it to be.
Why not carry that philosophy over into the filter side of TMDA
where things get more complex? We get questions from people who've
omitted ``import os'' and we just tell them it's required for TMDA
to work. Importing modules is much more complicated than an
if-then statement.
> I'm not sure we want to require entry level Python skills just to
> use TMDA.
Learning entry-level Python skills isn't any more difficult than
FilterParser, for the average TMDA user.
A non-technical person is going to fail at TMDA configuration long
before the filter is written. They're usually struggling to get
the MTA to deliver mail at all. We see this on -users every day.
I'm sorry, but the average Unix user should have a general
knowledge of programming syntax. Python's no harder than the shell
of their choice.
P.S. - I'm not in any way downplaying the beauty of FilterParser.
It's been the single most useful third-party contribution to the
project, and significantly enhanced TMDA's functionality. I just
want to stir discussion to make sure we don't pass up a valid
design suggestion.
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
