If the target computer does not have the fingerd daemon running you'll get a "Connection
-Refused" error. Paranoid sysadmins keep fingerd off or limit the
-output to hinder crackers and harassers. The above format is the standard
-fingerd default, but an alternate implementation can output
-anything it wants, such as automated responsibility status for everyone in an
-organization. You can also define pseudo "users", which are essentially
-keywords.
If the target computer does not have
+the fingerd daemon
+running you'll get a "Connection Refused" error. Paranoid sysadmins
+keep fingerd off or limit the output to hinder crackers
+and harassers. The above format is the standard fingerd
+default, but an alternate implementation can output anything it wants,
+such as automated responsibility status for everyone in an
+organization. You can also define pseudo "users", which are
+essentially keywords.
This portion of the tutorial makes use of factories and protocols as introduced in the Writing a TCP Server howto and @@ -75,11 +76,12 @@ over and over again, responding to network events and making scheduled calls to code.
-Note that there are actually several different reactors to choose from;
-from twisted.internet import reactor returns the current reactor.
-If you haven't chosen a reactor class yet, it automatically chooses the
-default. See the Reactor Basics HOWTO
-for more information.
Note that there are actually several different reactors to choose
+from; from twisted.internet import reactor returns the
+current reactor. If you haven't chosen a reactor class yet, it
+automatically chooses the default. See
+the Reactor Basics HOWTO for
+more information.
In brief, the code in FingerFactory above creates a Deferred,
-to which we start to attach callbacks. The deferred action in
-FingerFactory is actually a fast-running expression consisting of
-one dictionary method, get. Since this action can execute without
-delay, FingerFactory.getUser uses defer.succeed to
-create a Deferred which already has a result, meaning its return
-value will be passed immediately to the first callback function, which turns out
-to be FingerProtocol.writeResponse. We've also defined an
-errback (appropriately named FingerProtocol.onError) that
-will be called instead of writeResponse if something goes
-wrong.
In brief, the code in FingerFactory above creates a
+Deferred, to which we start to attach callbacks. The
+deferred action in FingerFactory is actually a
+fast-running expression consisting of one dictionary
+method, get. Since this action can execute without
+delay, FingerFactory.getUser
+uses defer.succeed to create a Deferred which already has
+a result, meaning its return value will be passed immediately to the
+first callback function, which turns out to
+be FingerProtocol.writeResponse. We've also defined
+an errback (appropriately
+named FingerProtocol.onError) that will be called instead
+of writeResponse if something goes wrong.
This example also makes use of a Deferred.
-twisted.internet.utils.getProcessOutput is a non-blocking version
-of Python's commands.getoutput: it runs a shell command
-(finger, in this case) and captures its standard output. However,
-getProcessOutput returns a Deferred instead of the
-output itself. Since FingerProtocol.lineReceived is already
-expecting a Deferred to be returned by getUser, it doesn't need to
-be changed, and it returns the standard output as the finger result.
This example also makes use of a
+Deferred. twisted.internet.utils.getProcessOutput is a
+non-blocking version of Python's commands.getoutput: it
+runs a shell command (finger, in this case) and captures
+its standard output. However, getProcessOutput returns a
+Deferred instead of the output itself.
+Since FingerProtocol.lineReceived is already expecting a
+Deferred to be returned by getUser, it doesn't need to be
+changed, and it returns the standard output as the finger result.
Note that in this case the shell's built-in finger command is
simply run with whatever arguments it is given. This is probably insecure, so
@@ -222,12 +227,14 @@
The web. That invention which has infiltrated homes around the world finally
-gets through to our invention. In this case we use the built-in Twisted web
-client via twisted.web.client.getPage, a non-blocking version of
-Python's urllib2.urlopen(URL).read(). Like
-getProcessOutput it returns a Deferred which will be
-called back with a string, and can thus be used as a drop-in replacement.
The web. That invention which has infiltrated homes around the
+world finally gets through to our invention. In this case we use the
+built-in Twisted web client
+via twisted.web.client.getPage, a non-blocking version of
+Python's urllib2.urlopen(URL).read().
+Like getProcessOutput it returns a Deferred which will be
+called back with a string, and can thus be used as a drop-in
+replacement.
Thus, we have examples of three different database back-ends, none of which change the protocol class. In fact, we will not have to change the protocol @@ -279,21 +286,22 @@ finger11.tac -
Instead of using reactor.listenTCP as in the above examples,
-here we are using its application-aware counterpart,
-internet.TCPServer. Notice that when it is instantiated, the
-application object itself does not reference either the protocol or the factory.
-Any services (such as TCPServer) which have the application as
-their parent will be started when the application is started by twistd. The
-application object is more useful for returning an object that supports the
-Instead of using reactor.listenTCP as in the above
+examples, here we are using its application-aware
+counterpart, internet.TCPServer. Notice that when it is
+instantiated, the application object itself does not reference either
+the protocol or the factory. Any services (such as TCPServer) which
+have the application as their parent will be started when the
+application is started by twistd. The application object is more
+useful for returning an object that supports the IService, IServiceCollection, IProcess, and sob.IPersistable interfaces with the given
-parameters; we'll be seeing these in the next part of the tutorial. As the
-parent of the TCPServer we opened, the application lets us manage
-the TCPServer.
sob.IPersistable
+interfaces with the given parameters; we'll be seeing these in the
+next part of the tutorial. As the parent of the TCPServer we opened,
+the application lets us manage the TCPServer.
With the daemon running on the standard finger port, you can test it with
the standard finger command: finger moshez.
This program has two protocol-factory-TCPServer pairs, which are both child
-services of the application. Specifically, the
-setServiceParent
-method is used to define the two TCPServer services as children of
-application, which implements
-IServiceCollection.
-Both services are thus started with the application.
This program has two protocol-factory-TCPServer pairs, which are
+both child services of the application. Specifically,
+the setServiceParent
+method is used to define the two TCPServer services as children
+of application, which implements IServiceCollection. Both
+services are thus started with the application.
The factory-creation methods, getFingerFactory and
-getFingerSetterFactory, follow this pattern:
The factory-creation methods, getFingerFactory
+and getFingerSetterFactory, follow this pattern:
twisted.internet.protocol.ServerFactory.twisted.internet.protocol.ServerFactory.self, but that's OK
-because as a bound method it has access to the service's self,
-which is what it needs. For getUser, a custom method defined in
-the service gets copied. For setUser, a standard method of the
-users dictionary is copied.self, but
+that's OK because as a bound method it has access to the
+service's self, which is what it needs.
+For getUser, a custom method defined in the service gets
+copied. For setUser, a standard method of
+the users dictionary is copied.
+
As an application
-Service , this new
-finger service implements the
-IService interface
-and can be started and stopped in a standardized manner. We'll make use of
+
As an application service , this new finger
+service implements the IService interface and can
+be started and stopped in a standardized manner. We'll make use of
this in the next example.
Since this version is reading data from a file (and refreshing the data every
-30 seconds), there is no FingerSetterFactory and thus nothing
-listening on port 1079.
Here we override the standard
-startService
-and
-stopService
-hooks in the Finger service, which is set up as a child service of
-the application in the last line of the code. startService calls
-_read, the function responsible for reading the data;
-reactor.callLater is then used to schedule it to run again after
-thirty seconds every time it is called. reactor.callLater returns
-an object that lets us cancel the scheduled run in stopService
-using its cancel method.
Since this verison is reading data from a file (and refreshing the data
+every 30 seconds), there is no FingerSetterFactory and thus
+nothing listening on port 1079.
Here we override the standard startService
+and stopService hooks in
+the Finger service, which is set up as a child service of the
+application in the last line of the code. startService
+calls _read, the function responsible for reading the
+data; reactor.callLater is then used to schedule it to
+run again after thirty seconds every time it is
+called. reactor.callLater returns an object that lets us
+cancel the scheduled run in stopService using
+its cancel method.
The same kind of service can also produce things useful for
-other protocols. For example, in twisted.web, the factory
-itself (Site) is almost
-never subclassed — instead, it is given a resource, which represents the tree
-of resources available via URLs. That hierarchy is navigated by
-Site and overriding it
-dynamically is possible with
-getChild.
The same kind of service can also produce things useful for other
+protocols. For example, in twisted.web, the factory itself
+(Site) is almost
+never subclassed — instead, it is given a resource, which
+represents the tree of resources available via URLs. That hierarchy is
+navigated by Site
+and overriding it dynamically is possible with getChild.
To integrate this into the Finger application (just because we can), we set
up a new TCPServer that calls the By overriding By
+overriding This is the sixth part of the Twisted tutorial Twisted from Scratch, or The Evolution of Finger. In this part, we demonstrate adding a web frontend using simple In this part, we demonstrate adding a web frontend using
+simple In this example we construct HTML segments manually. If the web interface
was less trivial, we would want to use more sophisticated web templating and
finger16.tac
-FingerService now has another new function,
-getIRCbot, which returns the
-ReconnectingClientFactory. This factory in turn will instantiate
-the IRCReplyBot protocol. The IRCBot is configured in the last
-line to connect to irc.freenode.org with a nickname of
-fingerbot.irc.IRCClient.connectionMade,
-IRCReplyBot can access the nickname attribute of the
-factory that instantiated it.FingerService now has another new
+function, getIRCbot, which returns
+the ReconnectingClientFactory. This factory in turn will
+instantiate the IRCReplyBot protocol. The IRCBot is
+configured in the last line to connect
+to irc.freenode.org with a nickname
+of fingerbot.irc.IRCClient.connectionMade, IRCReplyBot
+can access the nickname attribute of the factory that
+instantiated it.Add XML-RPC Support
Only in doc/core/howto/tutorial: .svn
diff -bu doc/core/howto/tutorial/web.xhtml doc/core/howto/tutorial/web.xhtml
--- doc/core/howto/tutorial/web.xhtml 2010-09-27 12:17:27.847250386 +0200
+++ doc/core/howto/tutorial/web.xhtml 2010-09-09 15:15:06.870913579 +0200
@@ -13,14 +13,16 @@
twisted.web.resource.Resource objects: UserStatusTree, which will produce a listing of all
-users at the base URL (/) of our site; UserStatus, which gives the status of each user at the
-location /username; and UserStatusXR,
-which exposes an XMLRPC interface to getUser and
-getUsers functions at the URL /RPC2.twisted.web.resource.Resource
+objects: UserStatusTree, which will
+produce a listing of all users at the base URL (/) of our
+site; UserStatus, which gives the status
+of each user at the locaton /username;
+and UserStatusXR, which exposes an XMLRPC
+interface to getUser
+and getUsers functions at the
+URL /RPC2.