Changes between and of Initial VersionVersion 2Ticket #2571


Ignore:
Timestamp:
04/15/2007 03:03:39 PM (7 years ago)
Author:
glyph
Comment:

I'm not sure I understand your comment.

I understand that there are certain structures this information could be put into which would not, by themselves, provide any way to determine if they were sufficient to configure twistd. However, a well-designed structure would be initialized in such a way that (barring stupid introspection tricks) any TwistdConfiguration object is a complete and valid configuration for a twistd process. So I think I'm agreeing with you when I say that it should be so designed.

However, this particular ticket is an attempt to separate the definition of all the external hooks for overriding the configuration object from the configuration object itself. Thanks to platform requirements (you must bind ports before shedding privileges, for example) each twistd subsystem will need to have its own timing for calling application code to override it, so tickets like #638 should still exist separately; they can just be facilitated by having an existing, well-defined structure to manipulate.

Regardless, as you say, this is probably worth it just for the testing benefits.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #2571 – Description

    initial v2  
    1 Currently twistd converts some options into objects ({{{app.ApplicationRunner}}} et. al., and some options into a series of function calls (runReactorWithLogging, fixPdb, runWithProfiler, etc). 
     1Currently twistd converts some  
     2 
     3options into objects ({{{app.ApplicationRunner}}} et. al., and some options into a series of function calls (runReactorWithLogging, fixPdb, runWithProfiler, etc). 
    24 
    35Before twistd does anything with the arguments that it's given, it should convert all of them into a set of introspectable, structured objects, which can be manipulated.