[Twisted-Python] Questions regarding serviceCollection and Interfaces.

[kgi]

Hi all.

I'm in the process of moving a skeleton asyncore application to
Twisted, and need some help. I'm hoping that someone with much Twisted
Enlightenment can point me gently in the direction of understanding.

(Amusingly enough, another poster recently summarised my exact
experiences: start with asyncore, find its limitations, do a bit of
shoehorning and end up trying with Twisted).

Because this is new code I want to do The Right Thing vis-a-vis the
latest Twisted coding techniques. Everything was peachy until I reached
a certain step in the "Evolution of Finger" Tutorial.

Until a certain point I had completely grokked the approach that looks
like this:


  class Foo ( Protocol ):
      ....

  factory = ServerFactory()
  factory.protocol = Foo

  application = service.Application ( "fooserver" )
  internet.TCPServer ( port, factory ).setServiceParent ( application )


However, then I reached:

  http://twistedmatrix.com/projects/core/documentation/howto/tutorial/components.html

and the approach morphed into:

  application = service.Application ( "fooserver" )
  f = FooService()
  serviceCollection = service.IServiceCollection ( application )
  internet.TCPServer ( port, IFooFactory ( f ) ).setServiceParent (
serviceCollection )


Here are my questions:

1. I simply don't understand the third line of the new approach! :-)

   In twisted.application.service.py, I see:

    class IServiceCollection(components.Interface):
      ....

   So, "IServiceCollection" is an Interface; my (possibly outdated)
understanding
   is that an interface is simply a specification that you can check
against when
   something claims to implement it, hence all the "implements(Yadda)" calls
   everywhere (presumably, an exception is raised when something tells porkies
   about what it implements).

   But in this case, it looks like we're actually instantiating an
interface class.
   I can't grok what this "means", especially in light of the fact that there
   is "MultiService" below it that implements IServiceCollection.

2. Similarly, in the last line, "IFooFactory(f)" is taking a Service
(which isn't
   a factory) and passing it as a construction argument to IFooFactory (which
   also isn't a factory). The result is used as an argument to
internet.TCPServer(),
   which expects a factory!

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()?

4. Lastly, there are lots of examples floating around that describe
   how each Protocol example can reference its own Factory in order for
   connections to be able to talk to other connections (for example, in
   the chat server example). However, what approach should I take when I
   have a single server with multiple Protocols?

   For example, consider a simple cache: I have a server which accepts
   TCP connections from lots of clients, and handles queries from
   these clients. The server actually gets information from an
   upstream server, but caches the results that it has already seen.

   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.


Many thanks for your time, and any assistance afforded!

Ricky