<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello Federico,<div><br></div><div>I would agree with you here. Personally, I think the trick with included applications complicates design and dependencies management. Here is my view on the problem of “dependency supervision”:</div><div><br></div><div>A dependent application provides variour resource to parent application. Those resources are either provided using start_link semantic or open/close paradigm (e.g. sockets). The start_link dependencies are manageable using supervisor tree of parent application. For example, you application uses cache, it instantiates cache bucket using start_link within root superior. The death & recovery of cache instance is handled by root supervisor of “parent” application. The second case is manageable in similar fashion with an exception that you have a client process that open/close and uses resource service. The failure of resource is propagated to client and it’s top supervisor. I do not see any reason why you need to implement extra supervision layer for these applications.</div><div><br></div><div>On another hand, you solution might be composed of sibling application, each is responsible for own subsystem. The concept of permanent applications and heart solves the problem of system recovery to consistent state. The failure or permanent application triggers VM failure and concequent recovery by heart application. My usual design of supevisor trees leads the application termination as ultimate, last resort recovery solution. My solutions are composed of multiple interchangeable nodes, the temporary loss of node is transparent to clients. </div><div><br></div><div>The usage of this model does not require any explicit supervision of application by it self. </div><div> </div><div> </div><div>Best Regards, </div><div>Dmitry</div><div><br></div><div><br></div><div><br><div><div>On 25 Jun 2014, at 20:48, Federico Carrone <<a href="mailto:federico.carrone@gmail.com">federico.carrone@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">We have been having a long discussion the previous months about included applications and supervision at our workspace.<div><br></div><div>Some of us just lists the needed applications in the .app file and make sure that all necessary application are started when our application starts. </div>
<div><br></div><div>For some teammates this has a big issue that: if a depencendy dies, our application's supervision tree will not know about it. They say that the system would be in an inconsistent state. So what they do is that they add the applications inside the included applications and they start the top level supervisor of each dependency inside our application supervisor tree.</div>
<div><br></div><div>I do not really like this since I think that each application should be separate.</div><div><br>I would REALLY like to know the community views and experiencies on this.</div><div><br></div><div>Thanks in advance,</div>
<div>Federico Carrone.</div><div><div><br></div>-- <br><div dir="ltr"><a href="http://federicocarrone.com/" target="_blank">http://federicocarrone.com/</a><br></div>
</div></div>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br></div></body></html>