On Fri, Jul 01, 2005 at 11:16:30AM -0700, Ned Freed wrote:
One thing that's bugged me about the vacation extension is that it's not
entirely self-contained, in that the database has to be attended to via
some external means.
I, OTOH, believe this to be one of the main strengths of this proposal,
and indeed of sieve in general.
Maybe you could explain more? The vacation database is entirely owned
by the delivery application, which ought to be able to completely control
that data as well, including instantiating it and validating it.
I infer from your comments (and correct me if I am wrong; I'm only
trying to understand) that you would mandate the use of helper tools in
maintaining seive scripts.
Of course such tools aren't mandatory. But it is silly to pretend that the vast
majority of users can be well werved by having them construct their own scripts
by hand, instantiating the underlying services, and so on.
That's a fine administrative perspective,
but I wouldn't want to see it as part of the language document, nor
require other administrators to think the same way. On the contrary, I
would hope that, as much as possible, the language would be designed to
simply work when correct syntax is used. I've described one problem
that the vacation extension has in this regard, and suggested a way to
address it. There may be better ways; it was just an idea.
Perhaps I'm alone in this; if so, well, that's the way it goes..
Our customers employ sieve to provide various services to literally millions of
end users, including but not limited to vacation reminders. And while there
have been issues, this sort of thing just doesn't come up at all, ever.
If you want an example of a real issue, the obvious one is sieve script
internationalization. More specifically, given vacation text in multiple
languages, what criteria do you use in your script to figure out which variant
Part of the problem with this particular issue is that there is often useful
out-of-band information that's available to the messaging system but there's no
way to access it through sieve. And even if I make the information available
through some sort of extension, using existing sieve language facilities to
perform language tag comparison and selection isn't easy.
If I were to propose additions to vacation, it would be in this general area,
not in enhancing the vacation database - what's there already appears to be
sufficient for the vast majority of users and uses.