http://twistedmatrix.com/documents/current/img/twisted-overview.png

이 하우투 문서안에 있는 다른 대부분의 문서들은 Twisted가 무엇인지를 정의하기위해 특정 목적에 맞춰져 있습니다. Here, I will attempt to explain not what Twisted is, but what it should be, once I've met my goals with it.

맨먼저 Twisted는 재미있습니다. 이 프로젝트는 게임으로서 시작되었으며, 현재도 게임에 상업적으로 사용되고 있고, 바라건데 앞으로도 최종사용자를 위한 대화적이고 즐거운 경험으로서 존재할 것입니다.

Twisted는 인터넷 어플리케이션을 개발하기위한 플렛폼입니다. 그 자체로서도 매우 강력한 언어인 파이선으로 되어있어 다른 언어에서는 부족한 추가하기에는 많은 시간이 소모되는 많은 기능들을 가지고 있습니다. 지금 당장 이러한 작업을 할 수 있습니다; Twisted는 훌륭한(다소 특이하긴하지만) 순수 파이선 프레임워크 또는 라이브러리이며, 여러분이 어떻게 다루느냐에 따라 용도가 결정되고, 계속적으로 발전중인 프로젝트입니다.

플렛폼으로서 Twisted는 통합에 촛점을 맞추고 있습니다. 이상적인 얘기일수 있지만 모든 기능은 모든 프로토콜을 통하여 접근이 가능하도록 되어있습니다.Failing that, all functionality should be configurable through at least one protocol, with a seamless and consistent user-interface. The next phase of development will be focusing strongly on a configuration system which will unify many disparate pieces of the current infrastructure, and allow them to be tacked together by a non-programmer.

Twisted Internet is a compatible collection of 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, select-based loop to the loops of various GUI toolkits like GTK+ or Tk. Twisted Internet also contains a powerful persistence API so that network programs can be shutdown and then resurrected with most of the code unaware of this.

Twisted Internet contains the various interfaces to the reactor API, whose usage is documented in the low-level chapter. Those APIs are IReactorCore, IReactorTCP, IReactorSSL, IReactorUNIX, IReactorUDP, IReactorTime, IReactorProcess and IReactorThreads. The reactor APIs allow non-persistent calls to be made.

Twisted Internet also covers the interfaces for the various transports, in ITransport and friends. These interfaces allow Twisted network code to be written without regard to the underlying implementation of the transport.

The IProtocolFactory dictates how factories, which are usually a large part of third party code, are written.

Twisted Web is a web application server written in pure Python, with APIs at multiple levels of abstraction to facilitate different kinds of web programming.

http://twistedmatrix.com/documents/current/img/web-overview.png

When the Web Server receives a request from a Client, it creates a Request object and passes it on to the Resource system. The Resource system dispatches to the appropriate Resource object based on what path was requested by the client. The Resource is asked to render itself, and the result is returned to the client.

Resources are the lowest-level abstraction for applications in the Twisted web server. Each Resource is a 1:1 mapping with a path that is requested: you can think of a Resource as a single page to be rendered. The interface for making Resources is very simple; they must have a method named render which takes a single argument, which is the Request object (an instance of twisted.web.server.Request). This render method must return a string, which will be returned to the web browser making the request. Alternatively, they can return a special constant, twisted.web.server.NOT_DONE_YET, which tells the web server not to close the connection; you must then use request.write(data) to render the page, and call request.finish() whenever you're done.

Web programmers seeking a higher level abstraction than the Resource system should look at Nevow, available as part of the Quotient project. Nevow is not distributed as part of Twisted.

Nevow is based on the same ideas as the earlier Woven framework. Woven only remains part of Twisted in order to support existing projects, and should not be used for new projects. Nevow is a simpler framework which retains the strengths of Woven.

Perspective Broker (affectionately known as PB) is an asynchronous, symmetric[1] network protocol for secure, remote method calls and transferring of objects. PB is translucent, not transparent, meaning that it is very visible and obvious to see the difference between local method calls and potentially remote method calls, but remote method calls are still extremely convenient to make, and it is easy to emulate them to have objects which work both locally and remotely.

PB supports user-defined serialized data in return values, which can be either copied each time the value is returned, or cached: only copied once and updated by notifications.

PB gets its name from the fact that access to objects is through a perspective. This means that when you are responding to a remote method call, you can establish who is making the call.

No other currently existing protocols have all the properties of PB at the same time. The particularly interesting combination of attributes, though, is that PB is flexible and lightweight, allowing for rapid development, while still powerful enough to do two-way method calls and user-defined data types.

It is important to have these attributes in order to allow for a protocol which is extensible. One of the facets of this flexibility is that PB can integrate an arbitrary number of services could be aggregated over a single connection, as well as publish and call new methods on existing objects without restarting the server or client.

1. There is a negotiation phase for banana with particular roles for listener and initiator, so it's not completely symmetric, but after the connection is fully established, the protocol is completely symmetrical.