[Twisted-Python] Re: ApplicationService orderization

[Bob Ippolito]

I don't have time for a large reply right now, but....

On Wednesday, Apr 9, 2003, at 17:30 America/New_York, Kevin Turner 
wrote:

> [Recap:  Last night, Bob was complaining that the order that services
> were started and stopped was undefined, saying
>
> Bob> well if you have service A dependent on service B
> Bob> and you don't want service A to actually start service B
> Bob> like let's say you have a database service or something
> Bob> and you have another service that wants to persist stuff using the
> Bob> database service
>
> so he made the order in which services are started defined as the order
> in which they were added to the service collection, and the reverse for
> stopping.]
>
> Bob, I fear this solution is too fragile if your services really depend
> on one another.  While it will work for now when installing services is
> something that happens once in mktap, I fear it'll break down with more
> dynamic service management.  Example::
>
>     application.addService("dataStore", StupidStorage())
>     application.addService("dataMaker", FooService())
>
>     # ...later, decide we have outgrown StupidStorage:
>     application.removeService("dataStore")
>     application.addService("dataStore", RealStorage())

Well nomatter what, unless it uses 
application.getServiceNamed("dataStore") everywhere, you just broke 
dataMaker.  If you're changing the storage you have bigger things to 
worry about than this little corner case.  You need to pause/stop 
FooService, export all the data from the existing storage, stop the 
existing storage, start the new storage, import all the data into the 
new storage, change FooService's reference to the new storage, 
resume/start FooService, and cross your fingers.

It is a good feature that services get started and stopped in a 
sensible order, there's no reason they shouldn't.  I didn't want to 
change the implementation to a list because that would've required more 
code to change, and had the capability to break existing stuff because 
there is no API iterate an AbstractServiceCollection (or the bastard 
Application class, which should be one but doesn't mixin IIRC).

>
> With your ordering, the new dataStore will now stop before dataMaker
> does.
>
> Instead of introducing ordering dependencies into the flat top-level
> service namespace, I think the right answer to your problem is to do as
> Chris suggested: Use a hierarchical structure by making dataStore a
> MultiService, and adding any dataMaker services at its children.  That
> way your dataStore can always make sure its children shut down before 
> it
> does.

That's only an issue if you use persisted Application objects, I don't. 
  What if you want to stop the storage without stopping it's children?  
In some cases, my ApplicationServices only depend on the storage for 
initialization anyways, so it wouldn't make sense to force them to shut 
down when the storage does.

>
> Does this work for you?  If so, I would like to revert your changes
> making Application.services an OrderedDict before the (imminent!)
> release, just because anything that requires a change to the
> persistnceVersion is a big potential spot for trouble.  We have no
> inter-version testing framework at all.

You can take out the version upgrade if it doesn't work.  I used an 
OrderedDict for that reason, it has the same interface as a normal 
dict..  so no change to the code (other than stopping in reverse order 
of keys, which will still work on a regular dict, and __init__ of 
course) were made.  The upgrade was purely so new services added to old 
application objects would have their start/stop order preserved.

-bob