So, Tv and itamar were on channel today, asking about Twisted
philosophy, persistance, and configurability. Lacking the
presence of anyone closer to the pure Twisted light, I tried
to be a good little minion and make the case... But since
I'm the guy who doesn't quite believe in .spl files, I wasn't
able to be terribly convincing.
And now I could try to play his side of the argument with you guys,
but ya know, it'd be so much easier for me to just let his words do
the talking. Scrollback excerpts:
<itamar|home> anyone who knows how twisted's config mechanism works?
<itamar|home> typically, glyph is on 24 hours a day unless I
actually want to talk to a twisted developer
<Acapnotic> Wait, Twisted has a config mechanism?
<itamar|home> well, its server are persistent
<itamar|home> you coifgure them and then can pickle them to disk
<itamar|home> my question is: how do I configure them?
<itamar|home> can this mechanism be used with other software
<Acapnotic> You load them up, set them, and re-pickle them. You
can also set them through the interactive python interface on the
telnet server, say
<Acapnotic> Now somehow, Glyph claims that this is easier than
having configuration files.
<Acapnotic> I am not yet convinced of that, however.
<itamar|home> I am
<itamar|home> my software right now needs either something like
that or an XML config file
<itamar|home> which'll end up being a pickle equivalent anyway, so
there's no point
<Acapnotic> itamar: Well, so far as I've been able to tell, there's
not overmuch magic there. 'mkfooserver' just creates an instance
of a server object and pickle.dumps it, twistd just pickle.loads it
and invokes its the run() method.
<itamar|home> Acapnotic: well, my configs are pretty complex
<Tv> Acapnotic: But all that does is make your "config settings"
into "command line settings".
<Tv> I don't see it making things very easy.
<Tv> And think about version upgrades.
<Tv> I see trouble with the approach; mostly losing the unix
ubiquitousness (sp?). I can grep my config files; I store them in
<Tv> DavidC_: You want every program to contain some UI or command
mechanism to fully configure it.
<Tv> There's a lot of things I'd wish someone would spell out about
twisted. One thing is "how do I version control my configuration?"
<Tv> And don't give a trivial example..
<Tv> I have multi-hundred-line config files here.
<Tv> Shared between n hosts, via CVS.
<Tv> I'd love to hear more of the twisted philosophy..
<Tv> Personally, I have _needed_ programmability in config files
<Tv> Acapnotic: Oh, I like version control. I wish I could put more
things into it.
<Tv> Have you ever screwed up a config file?
<Tv> Have you ever downgraded something, and found out it won't
understand the new config file, and had to recreate the config to
match the older version?
<Tv> The same reasons you version control source code.
<Acapnotic> tv: you should post to the list at
<Tv> Acapnotic: I'm not following any more lists until I have
migrated my mail to another domain :)
<Acapnotic> tv: bah, you don't have to follow it, just post ;)
<Acapnotic> Tv: so if you want programmable config, is there a
problem with just using python? In which case your configuration
process is a script that does "app = pickle.load(...) app['web'].
port = 8080 ; app.append(ChickenServer()) ; ... ; pickle.dump(app,
<Tv> Acapnotic: That may very well be what I'd do. But then the
mechanism needs to support _both_ getting config programmatically
and state from pickle, at the same time.
<Acapnotic> Well, if I follow this train, there is only the state
of the application, since it is persistant. That state may be
changed or examined programmaticly.
<Tv> I see something beautiful there, but..
<Tv> noone has yet explained persistence to me well enough to
<Acapnotic> but what happens when you upgrade? heh.
<Tv> What if a buggy program corrupts its state?
<Tv> Then you lose your config file also.
<Tv> There needs to be something else.
<Tv> Something that is less volatile.
<DavidC_> what do you mean? both config and state are the same
<Tv> config changes when *I* say it changes.
<itamar|home> nah, config is parsed and then "rendered" into state
<Tv> program can change it's state as it wants.
<Tv> Any bug in program must never change the port to bind to.
<Tv> I see config as sort of a factory for initial program states,
if you want to put it that way.
<itamar|home> lets say by mistake someone does "del serverInstace.
<itamar|home> and then shuts down the server
<itamar|home> the pickled state is now wrong
<DavidC_> well that would be a bug.
<itamar|home> the point is that if you have an external, version
controleld config file
<itamar|home> these bugs don't bite you, or even if they do at
least they don't effect the configuration