<div>Hi,</div>

<div> </div>

<div>I have an application with a structural pattern that comes up again and</div>

<div>again, and I would like to ask you how would you solve this.  My app has</div>

<div>two kinds of processes:  a singleton that is a server collecting data, and</div>

<div>workers that do some calculation and send the result to the server.</div>

<div>There can be any number of workers and there's usually one data</div>

<div>collector server.  I think this is a very simple and common architecture.</div>

<div>The problem with this is that the calculators have to know the pid of the</div>

<div>collector and the whole thing has to be supervised.</div>

<div> </div>

<div>The simplest solution is that under a main supervisor I spawn the collector</div>

<div>server and register it with a name.  Next to the collector I start another</div>

<div>supervisor that manages the pool of the calculators and those processes</div>

<div>simply use the collectors name as the message destination when they're</div>

<div>done with the jod.  The main supervisor uses one_for_one strategy, while</div>

<div>the subsupervisor is a simple_one_for_one.</div>

<div> </div>

<div>I feel that this is not the best I could do.  Another solution could be to</div>

<div>use rest_for_one in the top supervisor, not register a name for the</div>

<div>collector, but push down the pid of the top supervisor to the sub-</div>

<div>supervisor, and then in the init function of the sub-supervisor I can</div>

<div>ask the top supervisor (with a which_children() call) to give me the</div>

<div>pid of the collector.  So I can give it to the calculators as an argument.</div>

<div>Seems a bit difficult, but has the benefit not using a registered name</div>

<div>for a purely internal use case.</div>

<div> </div>

<div>There's also a wrong solution with a top supervisor with no static</div>

<div>children.  In that case I can start the children manually.  First I can</div>

<div>start the collector, then I have got the pid of it and can use it when</div>

<div>starting the calculators.  The problem here is that when the collector</div>

<div>gets restarted, the calculators won't have the right pid.  Even if the</div>

<div>top supervisor uses rest_for_one strategy, and the calculators get</div>

<div>restarted, there's no mechanism to start calculators with the new</div>

<div>pid of the collector.  (I can't give the supervisor a function that</div>

<div>describes the way how to restart the whole thing, can I?)</div>

<div> </div>

<div>This wrong approach can be fixed if the top level supervisor exits</div>

<div>when the collector or the sub-supervisor fails (that's a {one_for_one,</div>

<div>0, 1} supervisor setup) and a plus layer of supervision above this</div>

<div>supervisor gets into play.  But that's just too many layers and</div>

<div>supervisors for a simple thing like this, am I right?</div>

<div> </div>

<div>I believe that the whole thing boils down to that I have not much</div>

<div>control over the order of child starts and I can't move information</div>

<div>between children of the same supervisor.  It would be nice if a</div>

<div>supervisor could supply some sort of a local name registry for the</div>

<div>processes below them but as far as I know there's only a global</div>

<div>(node local) one that could be used here.</div>

<div> </div>

<div>Which architecture would you choose?  Are there other alternative</div>

<div>structures I haven't thought of?  What do you thing which one is the</div>

<div>best approach and why?</div>

<div> </div>

<div>I'm sorry for the long and beginner question.</div>

<div> </div>