[Twisted-Python] Questions regarding serviceCollection and Interfaces.

kgi iacovou at gmail.com
Wed Jul 6 10:18:53 EDT 2005

On Tuesday 05 July 2005 16:50, Itamar Shtull-Trauring wrote:
> On Tue, 2005-07-05 at 15:16 +0300, kgi wrote:
> >    I can't grok what this "means", especially in light of the fact that
> > there is "MultiService" below it that implements IServiceCollection.
> This is interface adaptation, see
> http://twistedmatrix.com/projects/core/documentation/howto/components.html
> for an expalantion.

Thanks for your answer, Itamar.

I've read the information at the link, and I think I've moved a few rungs up 
the grokking ladder now. I had previously read the Zope Interface 
introduction at:


but this mostly just talks about the relationship between interfaces and 
objects (i.e. lots of .providedBy() and implementedBy() examples), and 
doesn't touch interface adaptation and components.

I do have one question arising from the Zope documentation, though. In the 
link above, it says (abridged):

class IFoo(zope.interface.Interface):
    def bar(q, r=None):
        """bar blah blah"""
  Note that `bar` doesn't take a `self` argument.  Interfaces document
  how an object is *used*.  When calling instance methods, you don't
  pass a `self` argument, so a `self` argument isn't included in the
  interface signature.

Yet all the examples I've seen in the Twisted documentation have interface 
methods that contain "self" parameters; for example, from the link you sent 

from zope.interface import Interface

class IAmericanSocket(Interface):
    def voltage(self):
      """Return the voltage produced by this socket object, as an integer.

Is this simply a cosmetic thing (i.e. no code actually looks at the function 
signature) or is the Zope Interface documentation out of date or wrong?

> > 3. What do I gain by using a serviceCollection over an application as the
> >    serviceParent of a TCPServer? Come to think of it, what did I gain in
> > the first place with setServiceParent()?
> Services are setup as a tree; the application is the root of the tree.
> Services let you organize your code as pluggable self-contained parts
> that get startup and shutdown events. Of course, for a simple TCP server
> that doesn't give you much.

Got you, thanks.

> >    In this case in the server I need a Protocol/TCPServer server to
> >    handle the multiple clients, and a single Protocol/connectTCP
> >    client for the upstream connection. However, it's not clear to me
> >    how I would transfer the data from the lineReceived() method of the
> >    server Protocol to the sendLine() method of the client Protocol,
> >    since each Protocol can see its own Factory, but not the Factory of
> >    the other Protocol.
> myServerFactory.clientFactory = myClientFactory
> # and now server Protocol instances can do self.factory.clientFactory

OK, so it's as simple as just boshing in a new attribute. I guess I had got so 
hung up on not understanding the "service" stuff previously I was convinced 
the right way to access other Factories was via the serviceCollection.

Again, thanks for your answer.


P.S. I took so long in answering because I wanted to be able to answer 
maintaining the original message threading information (I know some people 
get really upset when you break threading), which eventually meant setting up 
a separate postfix server just for outgoing gmail email.

If anyone has any information on either (1) getting a single postfix instance 
to work with multiple relayhosts for multiple "identities", or (2) 
configuring kmail to send directly to gmail over TLS, I'd love to hear how 
you did it. I found lots of generic configuration info for kmail, but I 
couldn't get kmail to manage it whatever I did.

More information about the Twisted-Python mailing list