> You could work around this by optionally comma delimiting an attempts
> value in the <delayTime> tag...
An reasonable approach, but wrong execution. Whenever you have multiple
<tag> entries, the resulting value provided by the Mailet API is going to be
a CSV (comma separated value) String whose order reflects the order of the
<tag> elements. Therefore using a comma to delimit optional values within a
tag will be ambiguous with having multiple tags.
To use your example:
> <delayTime> msecs [, attempts]</delayTime>
> <delayTime> 600000 </delayTime>
> <delayTime> 600000, 3</delayTime>
That won't work because the resulting CSV would be "600000,600000,3", which
is ambiguous. I don't like the idea that the ambiguity is resolved by
saying that 3 is too low a number to actually be a delay value.
Some other format expressing repetition and/or units of time would be
acceptable, so long as the resulting CSV remains unambiguous. Since I'm not
writing the parser, I'll leave the format up to the parser author, so long
as it is reasonable. :-) As a mere suggestion, something like:
<delayTime> [attempts*]value[unit]</delayTime>
<delayTime> 600000 </delayTime>
<delayTime> 3*600000</delayTime>
would be unambiguous: "600000,3*600000". Attempts defaults to 1, unit
defaults to milliseconds. We could easily handle the attempts today, and
add support for other types of time [sec, min, hours, days, whatever]
whenever someone gets an itch to scratch.
I agree that the last value should be used for all retries up to the max for
which there isn't a specified delay.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
