ietf-mta-filters
[Top] [All Lists]

Re: Sieve extensions

1998-01-25 14:20:54
A client pre-processor does this better than mucking up the language.
Besides, I figure at most 5% of the users will write their own scripts and
probably 1% of those will have more than one server.  This is such a rare
case it's not worth worrying about in the server.  I want to see the
"support" command dropped from the language.

  Pre-processing is a good indication that one's language isn't
powerful enough.  Supporting "support" in an interpreter is *trivial*
- it's just a table lookup.  What's the problem?

I disagree. The use or non-use of a preprocessor basically says nothing about
the underlying language. There are all sorts of reasons one might want a
preprocessor. Some are good and some aren't. The fact that one of the most
common uses of preprocessing (the C langage) happens to be a case where the
preprocessor is used to fix up underlying language weaknesses is beside the
point.


Nor is the problem isn't that "support" isn't easy for servers to implement. It
is.

The problem lies in how "support" affects the way the language is used. People
will use the presence of "support" to justify all sorts of extensions. These
extensions will then be used willy-nilly, and they will be used *without*
support tests being made. We will then end up with massive interoperability
problems.

You are recreating the PostScript situation here. Nothing more and nothing less.

  In addition, I'd like to be able to write a client that
automatically generates scripts which use "support" to dynamically
discover interpreter capabilities.  I like the idea of writing a
client which can take advantage of new features but can produce
scripts which work with older servers as well.

I have no problem with facilities that discover the abilities of a given server
and then write scripts in accordance with those abilities. I do not, however,
think this justifies having a "support" language construct so that scripts can
be generated with conditionals around code that some servers don't understand.

  I don't think anyone was trying to argue that we should restrict the
semantics of the language, merely the way in which they're expressed.
And frankly, I don't see what the problem is with the proposed
restriction; the tagged block model produces code which looks just
like C, and works with *every* control structure I can think of.

I don't much care for the present structure because of the inter-block
communication required to implement control structures. However, I think I can
live with it if that's what people want.

  I'd personally much rather feed plugins a datastructure produced by
a generic parser.  "Just give the plugin access to the raw script" is
just *begging* for disaster, IMHO - plugins *will* get the parsing
wrong ("Well, in a while() block, you can use newline and CRLF, but in
a try/catch block you can only use CRLF..." No).  Having multiple
plugins trying to deal with each other when each one tries to use its
own little parser to do its own little thing will be a nightmare.
Having plugins do parsing is bad design (although you're welcome to do
it in your implementation if you want); defining Sieve in such a way
as to force server writers to have plugins do their own parsing seems
almost criminal.

All you have done here is erect a strawman and then attack it. Nobody is
arguing for multiple parsers. A single parser will do the job just fine.

The reason this multiple parser argument is a strawman is that many if not most
extensions will simply add functional forms to the language, not control
structures. Frankly, I don't _want_ to expose the ability to add control
structures via plugins in my implementation.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>