The Evolution of Finger: making a finger library

  1. Introduction
  2. Organization
  3. Easy Configuration


This is the tenth part of the Twisted tutorial Twisted from Scratch, or The Evolution of Finger.

In this part, we separate the application code that launches a finger service from the library code which defines a finger service, placing the application in a Twisted Application Configuration (.tac) file. We also move configuration (such as HTML templates) into separate files. Configuration and deployment with .tac and twistd are introduced in Using the Twisted Application Framework.


Now this code, while quite modular and well-designed, isn't properly organized. Everything above the application= belongs in a module, and the HTML templates all belong in separate files.

We can use the templateFile and templateDirectory attributes to indicate what HTML template file to use for each Page, and where to look for it.

Note that our program is now quite separated. We have:

Prototypes don't need this level of separation, so our earlier examples all bunched together. However, real applications do. Thankfully, if we write our code correctly, it is easy to achieve a good separation of parts.

Easy Configuration

We can also supply easy configuration for common cases with a makeService method that will also help build .tap files later:

And we can write simpler files now:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# simple-finger.tac # eg: twistd -ny simple-finger.tac from twisted.application import service import finger options = { 'file': '/etc/users', 'templates': '/usr/share/finger/templates', 'ircnick': 'fingerbot', 'ircserver': '', 'pbport': 8889, 'ssl': 'ssl=0' } ser = finger.makeService(options) application = service.Application('finger', uid=1, gid=1) ser.setServiceParent(service.IServiceCollection(application))
% twisted -ny simple-finger.tac

Note: the finger user still has ultimate power: he can use makeService, or he can use the lower-level interface if he has specific needs (maybe an IRC server on some other port? Maybe we want the non-SSL webserver to listen only locally? etc. etc.) This is an important design principle: never force a layer of abstraction: allow usage of layers of abstractions.

The pasta theory of design:


Version: 12.3.0