Browsing French translation

1683.

Twisted Internet is a collection of compatible event-loops for Python. It contains the code to dispatch events to interested observers and a portable API so that observers need not care about which event loop is running. Thus, it is possible to use the same code for different loops, from Twisted's basic, yet portable, <code>select</code>-based loop to the loops of various GUI toolkits like GTK+ or Tk.

1684.

Twisted Internet contains the various interfaces to the reactor API, whose usage is documented in the low-level chapter. Those APIs are <code class="API" base="twisted.internet.interfaces">IReactorCore</code>, <code class="API" base="twisted.internet.interfaces">IReactorTCP</code>, <code class="API" base="twisted.internet.interfaces">IReactorSSL</code>, <code class="API" base="twisted.internet.interfaces">IReactorUNIX</code>, <code class="API" base="twisted.internet.interfaces">IReactorUDP</code>, <code class="API" base="twisted.internet.interfaces">IReactorTime</code>, <code class="API" base="twisted.internet.interfaces">IReactorProcess</code>, <code class="API" base="twisted.internet.interfaces">IReactorMulticast</code> and <code class="API" base="twisted.internet.interfaces">IReactorThreads</code>. The reactor APIs allow non-persistent calls to be made.

1685.

Twisted Internet also covers the interfaces for the various transports, in <code class="API" base="twisted.internet.interfaces">ITransport</code> and friends. These interfaces allow Twisted network code to be written without regard to the underlying implementation of the transport.

1686.

The <code class="API" base="twisted.internet.interfaces">IProtocolFactory</code> dictates how factories, which are usually a large part of third party code, are written.

1687.

Upgrading Applications

1688.

Applications must frequently deal with data that lives longer than the programs that create it. Sometimes the structure of that data changes over time, but new versions of a program must be able to accomodate data created by an older version. These versions may change very quickly, especially during development of new code. Sometimes different versions of the same program are running at the same time, sharing data across a network connection. These situations all result in a need for a way to upgrade data structures.

1689.

Basic Persistence: Application and .tap files

1690.

Simple object persistence (using <code>pickle</code> or <code>jelly</code>) provides the fundamental <q>save the object to disk</q> functionality at application shutdown. If you use the <code class="API" base="twisted.application.service">Application</code> object, every object referenced by your Application will be saved into the <code>-shutdown.tap</code> file when the program terminates. When you use <code>twistd</code> to launch that new .tap file, the Application object will be restored along with all of its referenced data.

1691.

This provides a simple way to have data outlive any particular invocation of your program: simply store it as an attribute of the Application. Note that all Services are referenced by the Application, so their attributes will be stored as well. Ports that have been bound with listenTCP (and the like) are also remembered, and the sockets are created at startup time (when <code>Application.run</code> is called).

1692.

To influence the way that the <code class="API" base="twisted.application.service">Application</code> is persisted, you can adapt it to <code class="API">twisted.persisted.sob.IPersistable</code> and use the <code class="python">setStyle(style)</code> method with a string like <q>pickle</q> or <q>source</q>. These use different serializers (and different extensions: <q>.tap</q> and <q>.tas</q> respectively) for the saved Application.