On 4/22/2015 5:56 AM, bougyman wrote:
What more is needed and what would making this "first class" add or improve upon? Tj
This question has been in the back of my mind for several days now, giving it some off-and-on consideration.
The steps described are explicit and hard-coded into a service's ./run script. This design works "just OK" and ensures complicated start-up sequences can be carried out, but it does not allow easy replacement of child services. The catch is that the name of child(ren) will be "baked" into the parent ./run script.
The loosely-coupled approach taken by anopa (and my own work) allows easy replacement of a child service with some other service, at the cost of slightly increased complexity in the child's run script. The net effect is the same but the difference is subtle. It also forces the set-up of the child to consistently be in the child's ./run script and not the parent, because it isolates child set-up to its scope instead of potentially blurring it with the parent's ./run script; currently in my eyes this is important because it follows "separation of duty" and makes who-has-what-responsibility clear.
