On Tue, Apr 28, 2015 at 8:38 AM, Avery Payne <avery.p.payne_at_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
Received on Tue Apr 28 2015 - 14:18:10 UTC