Hi Fred, you know, I'm almost at (actually, beyond) the point where I think it would be best to scrap the idea for the time being. And no, I'm not being sulky or sth ;) Intention was good, but I'm aware that good intentions and good outcomes are different things. Proverb has it that the road to hell is paved with good intentions, and I'd rather avoid adding a cobblestone with my name on it ;)
To me (and thanks to you, jk ;)), it looks like there are just too many unknown dangers here, or known dangers whose impact we can't estimate. Especially the technical debt, resulting from the feature lacking sophisticated control over delays, sounds like a veritable can of worms. Once done and built in, it can't be taken back out. Anyway, I have been thinking why the request for delayed restarts keeps popping up (while, as you point out, there are known better solutions), and usually ends in tears and frustration (did I mention that I like to exaggerate at times? ^^;). When I try to put myself in the shoes of a user making such a request, what likely brings me to it is the fact that I have a rather simple problem: restarts happen too fast for the external resource my client depends upon. The solution seems also simple, if I could just make a supervisor wait a bit between restarts. How hard can it be to just wait? And, from the point of view of my specific, limited use case, I'm probably right, simple waiting would help, and no harm done. But now I'm told that instead I have to do it in a comparatively complicated way, that instead of having a knob to turn restart delays up and down as needed in the few spots where I need it, I have to implement backoff/retry logic etc myself in my client. If my client is really a 3rd party thingie that doesn't provide any backoff/retry logic itself, I'll probably have to write a wrapper around it, too. And do it all over again in other similar clients of mine, where otherwise I would just use the same knob, if only it was there! The IMO crucial point: I won't get my simple knob _for reasons that don't apply to me and my simple, limited use case_. With that in mind, I think the frustration resulting from such requests is at least understandable. So I wonder if we can't do anything for them. Without touching the supervisor, or another central component for that matter ;) Kind regards, Maria _______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
