wiki:FoolscapFeatures

New Features (relative to Perspective Broker)

As compared to twisted.spread, aka Perspective Broker, aka "PB", Foolscap offers an RPC/RMI system with the following improvements:

  • most inert Python types are serializable, including unicode and sets
  • clients and servers are implemented as Services, which share connections when possible and are easy to shut down
  • links are encrypted/authenticated by default (using SSL)
  • all objects are accessed through secure/unguessable "FURLs"
    • explicitly published objects can be accessed through well-known FURLs
  • you can declare method signatures (with "constraints", either in Interface classes or as method attribute/decorators)
    • this is both a precondition-enforcement tool (to guard your code against unexpected input types) and a convenient documentation tool
  • serializers for third-party classes can be registered using Adapters
  • serializers are more "streaming" than in oldpb
    • serializers can pause themselves, deferring serialization until later
    • serializers can be paused when the network pipe is full
  • Foolscap is architected to make it possible to rewrite serializers and deserializers in C, for speed
  • object graph depth is limited by available heap memory, not available stack depth
  • The "Reconnector" (Tub.connectTo) will maintain a connection to a given FURL, re-establishing it if necessary.
  • connections use configurable keepalive timers and "ping" generation to keep NAT table entries alive on otherwise idle connections
  • RemoteReference objects (a proxy to the real remote instance) can themselves be sent over the wire, causing a three-party handoff known as a "Gift". The recipient application code is oblivious to the process.

Other Features

Foolscap offers several non-RPC features as well:

  • an advanced logging system:
    • this records a continuous "black box" of events, which can then be packaged into a single-file "Incident Report" when something goes wrong, giving you insight into the events that led up to a crash.
    • the "logport" lets you connect to a running application and retrieve recorded events, subscribe to hear about new ones, and retrieve any Incidents that have occurred
    • applications can be easily configured to connect to a "log gatherer" and submit their logs and Incidents to it
    • log events are timestamped, prioritized, sequenced, hierarchical (eventA is a child of eventB), structured (can contain arbitrary arguments), and are serialized in a reversible fashion.
      • With a little code, a log event scanner can be written to filter messages on e.g. a specific argument being within a certain range or different from a related event. This is traditionally difficult to do with a text-based 'grep' expression, but easy to do with Python code.
  • an eventual-send operator, to reduce plan-coordination bugs, as beautifully explained in Mark Miller's Concurrency Among Strangers paper and his thesis Robust Composition.
    • closely related is the Promise, which offers a results-of-a-method-call object that can be used even before the results are actually available
    • (in development): Remote Promises and Promise Pipelining, tools to reduce network roundtrips by sending method-invocation information over the wire. This avoids a roundtrip in the common pattern where the first message looks up an object and the second message tells that object to do something.
  • the Foolscap Application Server (or "flappserver"), a convenient way for non-programmers to configure and deploy pre-written services that run over Foolscap connections. Two basic built-in services are "upload-file" and "run-command", which behave like a drop-box and a remote-control garage-door opener: the server controls precisely which directory gets the file or which command is run, and the client merely gets to trigger the action. No accounts, no passwords, no worries about filtering argument input, just a single secure FURL to grant access to the specific service.
    • a sample is included to show how to run the Git remote-push protocol over a flappserver link, using a FURL to access a repository instead of a server-side account and SSH key (which grants too much authority)
Last modified 8 years ago Last modified on 06/20/2009 02:39:09 AM