Deletions are marked like this.

[http://peak.telecommunity.com/irc-logs/2003-11-14.txt five tips]:

 

1)

[12:01:33] <pje> Just wanted to pop in and add a few ideas to JPL's Twisted-PEAK tutorial.

[12:01:48] <pje> If you have a bunch of properties in a namespace that you need to bind to, you can do something like this:

[12:02:14] <pje> myapp = binding.Make(lambda: config.Namespace('myapp'))

[12:02:26] <pje> And then all the things that use the property namespace can bind to it, e.g.:

[12:02:44] <pje> port = binding.Obtain('myapp/receiver-port')

[12:03:05] <pje> user = binding.Obtain('myapp/user')

[12:03:08] <pje> etc.

[12:03:33] <pje> In fact, if your items are all in a "flat" namespace like that, and the items map precisely to the same property names, you can actually use Delegate:

[12:03:50] <pje> user = password = resource = host = binding.Delegate('myapp')

[12:04:15] <pje> So that was tip #1.

2)

[12:04:43] <pje> Tip #2... don't import the Twisted reactor directly.

[12:05:02] <pje> Instead, use reactor = binding.Obtain(running.ITwistedReactor)

[12:05:39] <pje> This will ensure that any PEAK components will end up using the Twisted reactor, instead of PEAK's mini-reactor.

[12:06:09] <pje> E.g., if you use AdaptiveTask, or FastCGIRunner, or stuff like that.

3)

[12:07:12] <pje> Tip #3... don't override AbstractCommand.run(), override the _run() method instead.

[12:07:30] <pje> run() now has handy error trapping, and it may someday have some other helpful hooks.

[12:07:45] <pje> You can just override _run() to define the "meat" of your command-line app.

4)

[12:09:54] <pje> Tip #4, and this is kind of specific to Twisted...

[12:10:07] <pje> Use assembly events to set up listeners and tasks.

[12:11:21] <pje> Specifically, in the case of the Jabber and Site objects...

[12:11:49] <pje> You can set up binding.Make(lambda self: self.doSomething(), uponAssembly=True)

[12:12:06] <pje> bindings in these kinds of services that will cause them to register or start or listenTCP or whatever.

[12:12:35] <pje> They should have a 'reactor = binding.Obtain(running.ITWistedReactor)' as well, and use that to hook up to the reactor.

[12:13:11] <pje> A component that uses them can either delay creation (by not touching the binding), or define the binding as uponAssembly, in which case they'll start ASAP.

5)

[12:14:32] <pje> Tip #5... instead of creating a custom app class, use running.commands.EventDriven.

[12:15:31] <pje> This can be as simple as creating an instance of EventDriven(components=[svc1(), svc2(), ...])

[12:16:10] <pje> EventDriven has configuration properties for things like automatically shutting down after a time period, or based on how long the app's been idle.

[12:16:42] <pje> There's also a ZConfig schema for EventDriven, which means that you can create ZConfig schema extensions to describe your new services.

[12:17:07] <pje> And then the app Maniac's working on could just be a ZConfig file listing each of the services it's to run.

[12:17:59] <pje> So, there'd be no "main program" anywhere, actually.

[12:18:44] ** lex has joined us

[12:18:56] <pje> Actually, I think I've overstated the case for Maniac's app. His services need to talk to one another, as part of a component that connects them.

[12:19:13] <pje> You can still do that with ZConfig, of course, but it's a tad more work to set up.

[12:19:53] <pje> Whew. I think that's about it for now. :)