Design challenge: Simplify Container

[Jeff Lindsay]

Right now there is a special type of service called Container. The only difference is how it starts. It has a slightly different state machine and start() implementation that calls do_start() *before* starting children. Service normally calls do_start() *after* children. 

This doesn't seem like something to necessitate a new class and new concept. The hard part is that it involves changing the state machine. So I'd like to see if anybody else can come up with a clean way to enable Service to be configured somehow (maybe via class variable) to operate in these two modes without two separate classes. 

--
Jeff Lindsay
http://progrium.com

[Jeff Lindsay]

Perhaps it means simplifying the state machine so that start and stop are only one state instead of the two states for each (starting self and starting children, stopping self and stopping children). This would eliminate the non-trivial complexity of switching the order AND make the state machine more intuitive. But would we lose anything important from not have a state for starting children?

-jeff

[Jeff Lindsay]

Pretty sure this worked. There is a "containerless" branch now primarily around this commit:

https://github.com/progrium/ginkgo/commit/6872aafa39d8dcacc1385f5a00504f7635485173

Instead of using ServiceContainer, you just use Service and specify "start_before = True" in the class. Like this:

https://github.com/progrium/ginkgo/commit/6872aafa39d8dcacc1385f5a00504f7635485173#L1L154

As proposed, the state machine for service is dramatically simpler and the state machine for container is completely gone. The only downside is you won't know when a service is in a state of starting children vs starting self, but I don't think we ever cared. The resulting state machine is also much more intuitive. 

Can somebody please review before I merge into master?

-jeff

[Jeff Lindsay]

Oh, another limitation of this implementation is that have the ability for do_start to return NOT_READY (and let something else set ready later, likely in a greenlet) is only available when you don't set start_before. But I'm pretty sure that's fair/fine.

[Jeff Lindsay]

Somebody +1

[Jeff Lindsay]

Too much to move forward on, this has been merged into master.