| | 1 | |
| | 2 | = New Features (relative to Perspective Broker) = |
| | 3 | |
| | 4 | As compared to twisted.spread, aka Perspective Broker, aka "PB", Foolscap |
| | 5 | offers an RPC/RMI system with the following improvements: |
| | 6 | |
| | 7 | * most inert Python types are serializable, including unicode and sets |
| | 8 | * clients and servers are implemented as |
| | 9 | [http://twistedmatrix.com/documents/current/api/twisted.application.service.html Services], |
| | 10 | which share connections when possible and are easy to shut down |
| | 11 | * links are encrypted/authenticated by default (using SSL) |
| | 12 | * all objects are accessed through secure/unguessable "FURLs" |
| | 13 | * explicitly published objects can be accessed through well-known FURLs |
| | 14 | * you can declare method signatures (with "constraints", either in Interface |
| | 15 | classes or as method attribute/decorators) |
| | 16 | * this is both a precondition-enforcement tool (to guard your code against |
| | 17 | unexpected input types) and a convenient documentation tool |
| | 18 | * serializers for third-party classes can be registered using Adapters |
| | 19 | * serializers are more "streaming" than in oldpb |
| | 20 | * serializers can pause themselves, deferring serialization until later |
| | 21 | * serializers can be paused when the network pipe is full |
| | 22 | * Foolscap is architected to make it possible to rewrite serializers and |
| | 23 | deserializers in C, for speed |
| | 24 | * object graph depth is limited by available heap memory, not available |
| | 25 | stack depth |
| | 26 | * The "Reconnector" ({{{Tub.connectTo}}}) will maintain a connection to a |
| | 27 | given FURL, re-establishing it if necessary. |
| | 28 | * connections use configurable keepalive timers and "ping" generation to |
| | 29 | keep NAT table entries alive on otherwise idle connections |
| | 30 | * !RemoteReference objects (a proxy to the real remote instance) can |
| | 31 | themselves be sent over the wire, causing a three-party handoff known as a |
| | 32 | "Gift". The recipient application code is oblivious to the process. |
| | 33 | |
| | 34 | |
| | 35 | == Other Features == |
| | 36 | |
| | 37 | Foolscap offers several non-RPC features as well: |
| | 38 | |
| | 39 | * an advanced [/docs/logging.html logging system]: |
| | 40 | * this records a continuous "black box" of events, which can then be |
| | 41 | packaged into a single-file "Incident Report" when something goes wrong, |
| | 42 | giving you insight into the events that led up to a crash. |
| | 43 | * the "logport" lets you connect to a running application and retrieve |
| | 44 | recorded events, subscribe to hear about new ones, and retrieve any |
| | 45 | Incidents that have occurred |
| | 46 | * applications can be easily configured to connect to a "log gatherer" and |
| | 47 | submit their logs and Incidents to it |
| | 48 | * log events are timestamped, prioritized, sequenced, hierarchical (eventA |
| | 49 | is a child of eventB), structured (can contain arbitrary arguments), and |
| | 50 | are serialized in a reversible fashion. |
| | 51 | * With a little code, a log event scanner can be written to filter |
| | 52 | messages on e.g. a specific argument being within a certain range or |
| | 53 | different from a related event. This is traditionally difficult to do |
| | 54 | with a text-based 'grep' expression, but easy to do with Python code. |
| | 55 | * an eventual-send operator, to reduce plan-coordination bugs, as |
| | 56 | beautifully explained in Mark Miller's |
| | 57 | [http://www.erights.org/talks/promises/index.html Concurrency Among Strangers] |
| | 58 | paper and his thesis |
| | 59 | [http://www.erights.org/talks/thesis/index.html Robust Composition]. |
| | 60 | * closely related is the Promise, which offers a results-of-a-method-call |
| | 61 | object that can be used even before the results are actually available |
| | 62 | * (in development): Remote Promises and Promise Pipelining, tools to reduce |
| | 63 | network roundtrips by sending method-invocation information over the |
| | 64 | wire. This avoids a roundtrip in the common pattern where the first |
| | 65 | message looks up an object and the second message tells that object to do |
| | 66 | something. |
| | 67 | * the Foolscap Application Server (or "flappserver"), a convenient way for |
| | 68 | non-programmers to configure and deploy pre-written services that run over |
| | 69 | Foolscap connections. Two basic built-in services are "upload-file" and |
| | 70 | "run-command", which behave like a drop-box and a remote-control |
| | 71 | garage-door opener: the server controls precisely which directory gets the |
| | 72 | file or which command is run, and the client merely gets to trigger the |
| | 73 | action. No accounts, no passwords, no worries about filtering argument |
| | 74 | input, just a single secure FURL to grant access to the specific service. |
| | 75 | * a sample is included to show how to run the Git remote-push protocol over |
| | 76 | a flappserver link, using a FURL to access a repository instead of |
| | 77 | a server-side account and SSH key (which grants too much authority) |
