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.
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.
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.
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.
Only if the reactivation mechanism is totally incompetent and doesn't update
the handle.
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.
I think the costs of adding this far exsceed the benefits.
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.
This is really a different issue, and one that is best addressed with
a date sieve test (which is planned).
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?
I'm afraid I see nothing here that warrants an addition to the vacation
specification.
Ned