Re: allow use of proplists in supervisor start specs

On 09/03/2014 01:50 PM, Siri Hansen wrote:
> Personally, I think that changing Id to 'name' might not be necessary.
> Partly because this value is discussed as the "child identifier"
> everywhere in the documentation and partly because the type definition
> of it is term() (and not atom() or string()). So my suggestion is to
> change this key to 'id'.

Agree.

> The reasoning about 'intensity'/MaxR and 'period'/MaxT is more complex,
> I think. I agree that the old variable names (at least MaxT), are not
> super good. One reason for keeping to something similar to this is,
> however, that these names are used when describing the mechanism of
> restart escalation in some of the erlang books that already exist. And
> if you are familiar with the old format, then switching to the new
> format will of course be easier if the key names are easy to map. But on
> the other hand, if we could find really good names to use instead, then
> maybe it would be worth the change in order to ease the introduction for
> newcomers. Again personally, I am not sure that 'intensity' and 'period'
> are so much better than the old names...
>
> What we are talking about here is some kind of "restart frequency",
> although it is not really a frequency either - at least not a constant
> frequency. It's the limit for the number of restarts within a time
> window... Are the names max_restarts or restart_limit better than
> intensity. Is period ok, or time_frame, time_window ... ? Or should we
> stick to max_time to keep close to the old names?
>
> Would it make sense to put both values into a tuple using only one key
> (restart_frequency, ...?) in the map?

What about 'max_restarts' and simply 'time' (allow up to max_restarts 
over time seconds). Or perhaps even just 'seconds'? It'd make it more 
obvious what the value represents.

-- 
Loïc Hoguin
http://ninenines.eu
_______________________________________________
erlang-patches mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-patches