[Twisted-Python] Re: ApplicationService orderization

[Kevin Turner]

[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())

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.

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.

(This whole thing would have passed without comment had I not
encountered an error in upgradeVersion13 in the acceptance tests.  I
*think* I fixed that bug, but I haven't yet found out what triggered it
in the first place (it *should* have been *generated* with version 13,
why was it upgrading?), and who knows what other uglies are hiding in
the dark corners of application persistence.)

 - Kevin

-- 
The moon is first quarter, 46.3% illuminated, 7.0 days old.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: </pipermail/twisted-python/attachments/20030409/da7cda64/attachment.sig>