This now sounds like you're talking about limiting how many handles a given
script can specify. But I still don't see the point, since a given script can
only have one handle apply per incoming message, so the overriding limit
is still the number of remembered responses.
Rereading the draft:
NOTE: One way to implement the necessary mechanism here is to store a
hash of either the current handle and the recipient or, if no handle
is provided, a hash of the vacation action parameters specifying the
message content and the recipient. If a script is changed,
implementations MAY reset the records of who has been responded to
and when they have been responded to.
Implementations are free to limit the number of remembered responses,
provided the limit is no less than 1000. When limiting the number of
tracked responses, implementations SHOULD discard the oldest ones
first.
And since it talks about storing all responses in a large hash table,
this is probably not 1000 per handle, but 1000 in total. Perhaps we
should say that to be entirely clear.
I use one table per handle, throwing tables away when their handles are
no longer active, and thought it were 1000 entries per table, but the
number of tables was not limited. When I suggested the limit of 1000,
indeed I meant 1000 per table and never read that part again after it
was introduced. Having at least 1000 active handles sounds a little
much to me, but I could live with that, in case nobody wants to put an
additional limit to the minimum number of handles.
Michael