On Oct 10, 2016, at 4:38 PM, Daniel Sutcliffe <dan...@gmail.com> wrote: > Generically, can I somehow bubble up events through the Service > hierarchy, or should I communicate with external objects to the > hierarchy that can bubble down actions from higher up?
On Mon, Oct 10, 2016 at 8:02 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > Following the > <https://en.wikipedia.org/wiki/Single_responsibility_principle>, the service > hierarchy's job is just to make sure everything gets started up and shut > down together. > > It sounds to me like you have a pretty well-defined hierarchy which seems > like it fits into the service hierarchy because it's roughly parallel in > terms of which objects participate; however, you have very > application-specific semantics for this parallel hierarchy. Maybe this was my conceptual issue; the parallels were close enough that it just felt right to add the functionality to Twisted's Service Hierarchy - close enough that I was sucked into thoughts of modbusPollingClient IS-A Service... but keeping in mind the arguments of composition vs inheritance, I somehow finished up with modbusClientService HAS-A pollingLogic - whereas what I think you are recommending here is that that pollingLogic HAS-A modbusClientService and knows about a MultiService which it makes use of only to let the Application have overall control over starting and stopping all the active Services. Actually I just read this back through and am not sure this is actually really what you meant Glyph :-/ I do get that it seems I am grabbing the stick by the wrong end, I guess I'll just go back to reading more example code to see if I can find something that resonates with me as being close to what I'm trying to achieve. > [...] > When it's time to "stop" a service, do setServiceParent(None); when it's > time to "start" it, do setServiceParent(appropriateServiceParent). This > should take care of keeping your services in the appropriate state. I have to admit I had not even thought of using setServiceParent(None) to bring services down - looking at the source makes this concept clearer and potentially useful to me though > BTW, if you have stateful long-running services that have to self-modify > based on changing circumstances, you might want to also check out > https://github.com/glyph/automat to see if it can help you ensure that > everything's in a consistent state. I'm still really just prototyping at this stage, trying to find an architecture that fits what I believe should be quite a simple application that is reasonably well suited to Twisted, but once I've passed this stage if I do find myself needing a FSM that is beyond totally simple then I'll certainly give this a look. Thanks. /dan -- Daniel Sutcliffe <dan...@gmail.com> _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
