On Tue, Apr 28, 2015 at 8:38 AM, Avery Payne <avery.p.pa...@gmail.com> wrote:
> 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. I guess I don't know what this means, in practice. My child services generally know about the parent in their ./run script and the parent (sometimes) has to know about the children in his ./finish 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. My child scripts are definitely more complex than the parents. I've never had a problem replacing a child service, it's them who have to know about my "parents" and not the other way around. In practical terms: /etc/sv/postgresql/run does not know about any of his children, but /etc/sv/pgbouncer/run does know about his parent (postgresql) and /etc/sv/app_which_uses_pg/run does know about his parent (pgbouncer), but not his grandparent. None of the parents know anything about their children. > The net effect is > the same but the difference is subtle. > I'd like to see the difference in a code example. I haven't had a chance to dig in to anopa yet enough to see how they couple it mouse loosely. Tj
