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 previous version had the setter poke at the innards of the finger factory. This strategy is usually not a good idea: this version makes both factories symmetric by making them both look at a single object. Services are useful for when an object is needed which is -not related to a specific network server. Here, we define a common service -class with methods that will create factories on the fly. The service +not related to a specific network server. Here, we define a common service +class with methods that will create factories on the fly. The service also contains methods the factories will depend on.
-The factory-creation methods, getFingerFactory and
- getFingerSetterFactory, follow this pattern:
The factory-creation methods, getFingerFactory
+ and getFingerSetterFactory, follow this pattern:
twisted.internet.protoco
- Set the protocol class, just like our factory class would have.
- Copy a service method to the factory as a function attribute. The
- function won't have access to the factory's
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.
+ function won't have access to the factory's 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.
+
+
Thus, we stopped subclassing: the service simply puts useful methods and +
Thus, we stopped subclassing: the service simply puts useful methods and attributes inside the factories. We are getting better at protocol design: -none of our protocol classes had to be changed, and neither will have to +none of our protocol classes had to be changed, and neither will have to change until the end of the tutorial.
-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.