"Jason R. Mastaler" <[EMAIL PROTECTED]> writes:
> it's my fault if using a simple proprietary syntax instead of
> Python was a bad decision.
I don't think initially it was a bad decision. When the filter
language was first incarnated, <source> <match> <action> was
awesome. It seemed to fulfill our wildest mail-handling desires.
Alas, Internet e-mail, and particularly dubious mailing list
software, continued to bite us in the tail, presenting more and
more complications. That's when the ``tag'' feature came to life
thanks to Tim (and the apropos reorganization of FilterParser).
Throw in CDB, DBM, all the mailing list features, and delivery
options, and we're off needing to create more and more contructs to
handle all the features. All a programming language does is parse
input; why not use it if it's clear enough?
> The reason I did this is precisely because as you said, things
> are more complex on the filter side of TMDA. I was hesitant to
> make it as complicated as say maildrop or procmail, where the
> bulk of the support lists are questions on filter syntax and
> usage.
*That's* my point. If your language isn't proprietary, you can
punt that support to someone else, and in most cases get people who
are already familiar with some manifestation of the same syntax to
begin with.
I know exactly how to use rc.* on *BSD because they're shell
scripts. Shell scripts are right at home when a system boots
because the kernel execs a shell to run everything. Same reason I
like dot-qmail; they give you freedom to use what you already know.
I'm not saying Python's as ubiquitous as sh, but it's more well
known than FilterParser. And if somebody puts in a little effort
to learn how to write their TMDA filter files skillfully, they'll
have learned something useful apart from TMDA.
> In .tmda/config this isn't much of a problem, since everything
> can be done with easy to understand VARIABLE = VALUE pairs.
The basic <source> <match> <action> theme could still apply to
filter files even with Python syntax. You simply throw in a
function call with a couple of arguments if you want to do
something extra.
> Even so, we still field Python syntax questions and mistakes on
> -users. It's hard to say whether this will increase exponentially
> if the filters become Python programs as well.
Those questions rarely aren't solved by ``you forgot "import os"''
or ``you need os.path.expanduser().'' People just kinda say ``OK''
and move on. I would think a calling a method nested beneath an
inherited object instance like the above would confuse people, but
it doesn't seem to[1]. More importantly, they don't have to use it if
they don't want to.
>> Learning entry-level Python skills isn't any more difficult than
>> FilterParser, for the average TMDA user.
>
> I'm not sure I agree with you here. I think the line-by-line
> <source> <match> <action> format of a filter file is quite easy even
> for a non-programmer to understand.
Those lines often turn into multiple-line, tagged, -argument
monstrosities, though. This isn't much more confusing even though
you've added a bunch of parens and commas:
if recipient == '[EMAIL PROTECTED]':
TMDA.tag({'from: '[EMAIL PROTECTED]',
'reply-to': ['dated', '1w']})
The benefit of having the power of a full language at your disposal
dwarfs the minor inconvenience of typing a few punctuations marks.
if sender == '[EMAIL PROTECTED]':
myfunc(Drew.BOUNCE, Drew.BOUNCE_MESS)
myfunc(Drew.FORWARD, '[EMAIL PROTECTED]')
Although, after writing it out, the API implementation would
probably be just as bloated as the filtering language.
And, you can already acheive this by delivering to a pipe. Maybe
it is overkill. Oh well, perhaps my rambling has sparked some
ideas from someone else.
Footnotes:
[1] That's probably contributed to the beauty of OO design philosophy.
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
