james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Soeren Hilmer <soren.hil...@tietoenator.com>
Subject Re: RemoteDelivery progressively increasing delay-time
Date Mon, 06 Oct 2003 07:53:41 GMT
I will start working on this today, and given all the input on potential 
pitfalls (thanks) I will go for a close match to Noels mail below, if my itch 
is to great I might go for the msec/sec/... thingy

--Søren

On Friday 03 October 2003 17:52, Noel J. Bergman wrote:
> > 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org

-- 
Søren Hilmer, M.Sc.
R&D manager		Phone:	+45 70 27 64 00
TietoEnator IT+ A/S	Fax:	+45 70 27 64 40
Ved Lunden 12		Direct:	+45 87 46 64 57
DK-8230 Åbyhøj		Email:	soren.hilmer@tietoenator.com


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message