Subject: vacation stuff

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 1 Jul 2005 13:25:00 -0400

Hi-

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.  For any given vacation handle there are at least
the following data duties:

Instantiation.  This is easy enough: the very first time the vacation
statement is executed, the implementation can simply create the
database.

Deletion.  Script author removes the vacation statement (or disables
it).  Deletion of data has to be done separately.  An environment can
certainly provide for this in some site-specific way.  OTOH the data
doesn't have to be deleted; in practice it does no harm, and users of
other vacation mechanisms probably don't always delete their vacation
database either (until the next initialization wipes it).  OTOOH,
a script writer who always uses different handles would cause old
data to pile up.  Might be worth some words of warning.

Reinstantiaton: Script author re-activates a vacation statement with the
same handle as before.  Stale data can be a problem here if the re-use
happens soon after the previous use.

One possible solution would be to introduce yet another argument or
option to the vacation statement, one that gives an instance key.  The
key could be any string, but there could be recommendations of common
choices, e.g. a date string 'yyyymmdd' of when the vacation is over
would be a convenient unique value.  This instance key would be stored
in the database that's associated with the vacation handle's data;
whenever a vacation statement is executed, if the stored key doesn't
match the specified key, the data would be re-initialized.

Alternatively, one could make it explicitly an ":end" value, so that
vacation action stops working on that date even if the author doesn't
update the script right away.

A downside would be that if the script has related vacation statements
in multiple places (which is sort of the point of :handle), the author
would have to be careful to keep the instance keys the same.  But that's
only a slightly greater burden than keeping the handles the same.

Thoughts?

mm

---

From: Ned Freed <[email-masked]>
Date: Fri, 01 Jul 2005 11:16:30 -0700 (PDT)

> some external means.

I, OTOH, believe this to be one of the main strengths of this proposal,
and indeed of sieve in general.

> For any given vacation handle there are at least

> data to pile up.  Might be worth some words of warning.

I fail to see any real added risk here. Consider: Vacation can be executed at
most once per incoming message, so the maximum number of database entries the
vacation action can produce per incoming message is one. So, if the intent is
to fill up the database, the simplest way to do it is set up regular vacation
without a handle setting and send in a bunch of messages from different
sources. Note. however, that implementations are free to limit the number of
remembered responses, so this trick will only work if the implementation allows
it.

Now suppose we add handle to the mix. It cannot be used to get past the "one
entry per message" limit - there still has to be one message sent per database
entry. Can it be used to, say, cause duplicate messages to create separate
database entries? Sure, but only if you're willing to create a vast long script
that tests some highly variable piece of message data and switches to a
different handle on that basis. (Remember that use of vacation parameters MUST
NOT have had variables expanded prior to their use in response tracking.)

Constructing a vast script in order to do something with duplicate message that
could much more easily be done with distinct message is a truly negligable risk
IMO.

> happens soon after the previous use.

Only if the reactivation mechanism is totally incompetent and doesn't update
the handle.

> match the specified key, the data would be re-initialized.

I think the costs of adding this far exsceed the benefits.

> update the script right away.

This is really a different issue, and one that is best addressed with
a date sieve test (which is planned).

> Thoughts?

I'm afraid I see nothing here that warrants an addition to the vacation
specification.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Sat, 2 Jul 2005 13:53:36 -0400

> 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.  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..

> NOT have had variables expanded prior to their use in response tracking.)

As I said, "in practice it does no harm."  I was simply thinking of the
potential for little bits of data to accumulate over time, especially
with somebody who writes scripts by hand and might choose a different
handle each time.  At any rate it's hardly the point of the message,
it was only a casual side remark. 

Yours,
-mm-

---

From: Ned Freed <[email-masked]>
Date: Sat, 02 Jul 2005 14:36:32 -0700 (PDT)

> 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,

> 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
to use?

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.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 4 Jul 2005 13:48:28 -0400

Hi-

Thanks for the clarifications.

> by hand, instantiating the underlying services, and so on.

Yes that would be silly.  But that's kind of a flip of what I am saying;

> have been issues, this sort of thing just doesn't come up at all, ever.

I can't speak for millions, but I completely agree with you that most
people, here too, will use helper tools to create and install Sieve
scripts.  But of course I wasn't trying to address them.  My feeling is
that any script and any defined language should, if it can be arranged
easily, work as well as it can per its definition, without such external
tools.

But I don't really want to repeat myself.  Others can weigh in if they
care, as some have; and (as with the 'auth envelope' thing) I can
certainly have a private extension that enables this sort of facility.
But I did want to bring it up.

Yours,
-mm-