* Release 0.12.6 (12-Jan-2017)
This is a minor release to improve compatibility with Twisted and I2P.
In this release, the Foolscap test suite no longer uses several deprecated
and/or internal Twisted attributes, so it should pass cleanly on the next
release of Twisted (which will probably be named Twisted-17.0.0).
In addition, the I2P connection handler was enhanced to let applications pass
arbitrary kwargs through to the underlying "SAM" API.
Finally connection-status error messages should be slightly cleaner and
provide more useful information in the face of unrecogized exceptions.
* Release 0.12.5 (07-Dec-2016)
** Connection Status Reporting
This release adds an object named `ConnectionInfo`, which encapsulates
information about a connection (both progress while being established, and
the outcome once connected). This includes which connection hint was
successful, what happened with the other hints, which handlers were used for
each, and when the connection was made or lost. To get one of these, use
`tub.getConnectionInfoForFURL(furl)` any time after `getReference()` is
called, or `rref.getConnectionInfo()` after it resolves. #267
It also adds `ReconnectionInfo`, a similar object for Reconnectors. These
capture the state of reconnection process (trying, established, waiting), and
will provide a `ConnectionInfo` for the most recent (possibly successful)
connection attempt. The API is `reconnector.getReconnectionInfo()`. #268
For details, see "Connection Progress/Status" and "Reconnector Status" in
`doc/using-foolscap.rst`.
** Connection Handler API Changes
To support `ConnectionInfo`, the Connection Handler API was changed.
The one backwards-incompatible change was that the `hint_to_endpoint()`
method now takes a third argument, to update the status as the handler makes
progress. External handler functions will need to be modified to accept this
new argument, and applications which use them should declare a dependency
upon the latest Foolscap version, to avoid runtime breakage.
Several backwards-compatible changes were made too: handlers can provide a
`describe()` method (which feeds `ConnectionInfo.connectionHandlers`), and
they can now set a special attribute on any exception they raise, to further
influence the status string.
In addition, the `tor.control_endpoint_maker()` handler now accepts an
optional second argument, which causes the maker function to be called with a
additional `update_status` argument. This backwards-compatible change allows
the maker function to influence the `ConnectionInfo` status too.
The Tor connection handler was enhanced to report distinct statuses for the
different phases of connection: launching a new copy of Tor, connecting to an
existing Tor daemon, etc.
** Minor Fixes
Foolscap-0.12.0 broke `flappserver create`, causing the command to hang
rather than exiting cleanly (although the flappserver directory itself was
probably created properly). This release finally fixes it. #271
* Release 0.12.4 (27-Sep-2016)
** Improvements
The TCP connection-hint handler can now accept square-bracket-wrapped IPv6
addresses in colon-hex format. You can produce FURLs with such hints by doing
this:
tub.setLocation("tcp:[2001:0DB8:f00e:eb00::1]:9900")
Foolscap Tubs have been using the IPv6-capable `HostnameEndpoint` since
0.11.0, so this completes the IPv6 support. Note that there are no provisions
for automatically detecting the host's IPv6 addresses: applications that wish
to use addresses (instead of hostnames) must discover those addresses on
their own. #155
A new `tor.control_endpoint_maker()` handler function was added, which is
just like `tor.control_endpoint()` but accepts a callable function, which
will be invoked only when a `tor:` hint is encountered. The function can
return a Deferred which yields the control endpoint. This allows lazy
launching of a Tor daemon, which can also be shared with other application
needs, such as listening on an Onion service. #270
* Release 0.12.3 (01-Sep-2016)
** Improvements
The `tor.socks_port()` handler was replaced by `tor.socks_endpoint()`, which
takes an Endpoint object (just like `tor.control_endpoint()` does). This
enables applications to speak SOCKS to the Tor daemon over e.g. a Unix-domain
socket. The `tor.socks_port()` API was removed, so applications using it must
upgrade. #265
The `allocate_tcp_port()` utility function would occasionally return ports
that were in use by other applications, when those applications bound their
own port to the loopback interface (127.0.0.1). allocate_tcp_port should no
longer do this.
* Release 0.12.2 (28-Aug-2016)
** Improved Tor Connection Handler
The `tor.control_endpoint` connection handler now properly handles the
config.SocksPort response provided by the debian Tor daemon (and possibly
others), which included a confusing unix-domain socket in its response.
The `tor.socks_port` handler was changed to accept both hostname and port
number. Using anything but "localhost" or "127.0.0.1" is highly discouraged,
as it would reveal your IP address to (possibly hostile) external hosts. This
change was made to support applications (e.g. Tahoe-LAFS) which accept
endpoint strings to configure socks_port, but then parse them and reject
anything but TCP endpoints (to match Foolscap's current limitations). Such
applications ought to warn their users to use only localhost.
* Release 0.12.1 (20-Aug-2016)
** Connection Handlers for SOCKS, Tor, I2P
Foolscap now includes importable connection handlers for SOCKS(5a), Tor, and
I2P. #242, #246, #261
These handlers require additional supporting libraries, so they must be
imported separately, and a setuptools "extra feature" declaration must be
used to ask for the supporting libs. For example, applications which want to
use `tor:` hints (on a host with a Tor daemon running) should have a setup.py
with:
install_requires=["foolscap[tor]"],
and the Tub setup code should do:
from foolscap.connections import tor
tub.addConnectionHintHandler("tor", tor.default_socks())
Full examples and docs are available in docs/connection-handlers.rst.
The default connection-negotiation timeout was increased from 60s to 120s, to
accomodate tor/i2p daemon startup times.
* Release 0.12.0 (20-Jul-2016)
** API changes: no more automatic configuration
Foolscap has moved from automatic listener configuration (randomly-allocated
TCP ports, automatically-determined IP address) to using more predictable
manual configuration. In our experience, the automatic configuration only
worked on hosts which had external IP addresses, which (sadly) is not the
case for most computers attached to the modern internet. #252
Applications must now explicitly provide Foolscap with port numbers (for
Tub.listenOn) and hostnames (for Tub.setLocation). Applications are
encouraged to give users configuration controls to teach Foolscap what
hostname and port number it should advertise to external hosts in the FURLs
it creates. See https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2773 for ideas.
The specific API changes were:
- Tub.setLocationAutomatically() has been deprecated
- Listener.getPortnum() has been deprecated
- calling Tub.listenOn("tcp:0") is also deprecated: callers should allocate a
port themselves (the foolscap.util.allocate_tcp_port utility function,
which does not block, has been added for this purpose).
Foolscap tools like "flappserver create" and "flogtool create-gatherer" will
no longer try to deduce their external IP address in an attempt to build
externally-reachable FURLs, and will no longer accept "tcp:0" as a listening
port (they now default to specific port numbers). Instead, they have
--location= and --port arguments. The user must provide '--location' with a
connection-hint string like 'tcp:hostname.example.org:3117' (which is put
into the server's FURLs). This must match the corresponding '--port'
argument, if provided.
- for all tools, if '--port' is provided, it must not be tcp:0
- 'flappserver create' now requires --location, and '--port' defaults to
tcp:3116
- 'flogtool create-gatherer' requires --location, default port is tcp:3117
- 'flogtool create-incident-gatherer' does too, default is tcp:3118
For backwards-compatibility, old flappservers will have "tcp:0" written into
their "BASEDIR/port" file, and an empty string in "BASEDIR/location": these
must then be edited to allow the flappserver to start. For example, write
"tcp:12345" into "BASEDIR/port" to assign a portnumber, and
"tcp:HOSTNAME:12345" into "BASEDIR/location" to expose it in the generated
FURL.
** Other API changes
Tub.listenOn() now takes a string or an Endpoint (something that implements
twisted.internet.interfaces.IStreamServerEndpoint). This makes it possible to
listen on non-IPv4 sockets (e.g. IPv6-only sockets, or unix-domain sockets,
or more exotic endpoints), as long as Tub.setLocation() is set to something
which the other end's connection handlers can deal with. #203#243
The "DefaultTCP" handler (which manages normal "tcp:HOST:PORT" connection
hints) has been moved to foolscap.connections.tcp . This makes room for new
Tor/I2P/SOCKS handlers to live in e.g. foolscap.connections.tor . #260
Connection handlers are now allowed to return a Deferred from
hint_to_endpoint(), which should make some handlers easier to write. #262
Note that RemoteReference.notifyOnDisconnect() will be deprecated in the next
release (once all internal uses have been removed from Foolscap).
Applications should stop using it as soon as possible. #42#140#207
** Compatibility Changes
This release removes support for the old (py2.4) "sets" module. This was
retained to support applications which were trying to maintain py2.4
compatibility, but it's been so long since this was necessary, it's time to
remove it.
** Other Changes
The internal `allocate_tcp_port()` function was fixed: unexpected kernel
behavior meant that sometimes it would return a port that was actually in
use. This caused unit tests to fail randomly about 5% of the time. #258
IPv6 support is nearly complete: listening on a plain TCP port will typically
accept connections via both IPv4 and IPv6, and the DefaultTCP handler will do
a hostname lookup that can use both A and AAAA records. So as long as your
server has a DNS entry that points at its IPv6 address, and you provide the
hostname to Tub.setLocation(), Foolscap will connect over IPv6. There is one
piece missing for complete support: the DefaultTCP connection handler must be
modified to accept square-bracketed numeric IPv6 addresses, for rare
situations where the host has a known (stable) IPv6 address, but no DNS name.
* Release 0.11.0 (23-Mar-2016)
** Packaging Fixes
Foolscap now declares a dependency on "twisted[tls]" instead of just
"twisted": the "[tls]" extra means "we need Twisted and its TLS support".
That's how we ask for Twisted to depend upon service_identity and other
supporting packages. By using "[tls]", we no longer need to manually depend
upon service_identity ourselves. If Twisted switches to some other scheme for
TLS support, this will correctly ask for that to be included. (#249)
Note that we still depend on pyOpenSSL ourselves, because we need its code to
control certificate validation (if Twisted actually moved away from pyOpenSSL
for TLS, Foolscap might break altogether).
The Twisted dependency was updated to >=16.0.0 (the current version), to get
an important HostnameEndpoint fix (#155).
The "flogtool", "flappserver", and "flappclient" executables are now provided
as "entry_points" on all platforms, not just windows. The old bin/* scripts
have been removed. The "flogtool" entrypoint was fixed (a one-character typo
in the setup.py specification): apparently it was always broken on windows
and nobody noticed.
We now use "tox" to run tests, instead of "trial foolscap", although the
latter is still fine when run in a virtualenv into which Foolscap has been
installed (and is what "tox" does under the hood).
This release also moves all source code from "foolscap/" to "src/foolscap/",
which should avoid some confusion as to which code is being tested.
Developers who work from a git checkout should manually "rm -rf foolscap"
after pulling this change, because otherwise the leftover .pyc files are
likely to cause spurious test failures. (#250, #251)
** partial IPv6 support
Foolscap's outbound connections now use HostnameEndpoint, which means that
connection hints which contain DNS names which map to AAAA (and maybe A6)
records should successfully connect to those IPv6 addresses. There is not yet
any support to *listen* on IPv6 ports, so this probably does not enable IPv6
completely. But a client running this release may be able to connect to
server running some future IPv6-capable release and advertising v6-based
hostnames. (#155)
* Release 0.10.1 (21-Jan-2015)
** Packaging Fixes
This release fixes a version-string management failure when the "log
publisher" feature was used in a tree built from a release tarball (rather
than from a git checkout). This caused a unit test failure, as well as
operational failures when using `flogtool tail`. Thanks to Ramakrishnan
Muthukrishnan (vu3rdd) for the catch and the patch. (#248)
* Release 0.10.0 (15-Jan-2015)
** Compatibility Fixes
This release is compatible with Twisted-15.3.0 through 15.5.0. A change in
15.3.0 triggered a bug in Foolscap which produced a somewhat-infinite series
of log messages when run under `twistd`. This release fixes that bug, and
slightly changes the semantics of calling `log.msg()` with additional
parameters. (#244)
Foolscap no longer claims compatibility with python-2.6.x . Twisted-15.5.0
was the last release to offer 2.6 support, and subsequent releases actively
throw errors when run against 2.6, so we've turned off Foolscap's automated
testing for 2.6. It may remain compatible by accident for a while. (#245)
* Release 0.9.1 (21-Sep-2015)
Point release to deal with PyPI upload problems. No code changes.
* Release 0.9.0 (21-Sep-2015)
** Plugins for Connection Handlers (#236)
New types of connection hints can now be used, by installing a suitable
connection handler into the Tub. These hints could point to I2P servers or
Tor hidden-service (.onion) addresses. The built-in TCP handler can be
replaced entirely to protect a client's IP address by routing all connections
through Tor. Implementation of these plugins are left as exercise for the
reader: Foolscap only provides the built-in "DefaultTCP" handler. See
doc/connection-handlers.rst for details.
** Shared Listeners are removed (#239)
Until this version, it was possible to create a single Listener that serviced
multiple Tubs (by passing the Listener returned from `l=tubA.listenOn(where)`
into `tubB.listenOn(l)`). This seemed useful a long time ago, but in fact was
not, and the implementation caused irreparable problems that were exposed
while testing the new connection handlers. So support for shared Listeners
has been removed: Tubs can still use multiple Listeners, but each Listener
now services at most one Tub. In particular, `Tub.listenOn()` now only
accepts a string, not a Listener instance.
Note that relays and redirects are still on the roadmap, but neither feature
requires sharing a Listener between multiple local Tubs.
** Extended-Form Connection Hints are removed
Support for extended-form connection hints has been removed. These were hints
with explicit key names like "tcp:host=example.org:port=12345", or
"tcp:example.org:timeout=30". They were added in the 0.7.0 release, but since
then we've realized that this is power that should not be granted to external
FURL providers.
The parser now only accepts "tcp:example.org:12345" and "example.org:12345".
Foolscap has never particularly encouraged applications to call
Tub.setLocation() with anything other than these two forms, so we do not
expect any compatibility problems.
** Option to Disable Gifts (#126)
"Gifts", more precisely known as "third-party reference introductions", occur
when one Tub sends you a message that includes a reference to some object on
a third Tub. This allows references to be passed around transparently,
without regard to which Tub they live on (yours, mine, or theirs), but allows
other Tubs to cause you to create network connections to hosts and ports of
their choosing. If this bothers you, the new `tub.setOption("accept-gifts",
False)` option instructs your Tub to reject these third-party references,
causing the calls that used them to signal a Violation error instead.
** Unreachable Tubs now fully supported (#208)
Unreachable "client-only" Tubs can be created by simply not calling either
`tub.listenOn()` nor `tub.setLocation()`. These Tubs can make outbound
connections, but will not accept inbound ones. `tub.registerReference()` will
throw an error, and Gifts delivered to third parties will not work.
Previous versions suggested using `tub.setLocation("")`: this is no longer
recommended.
** new util.allocate_tcp_port() function
To support a future deprecation of `Tub.listenOn("tcp:0")`, the new
allocate_tcp_port() function was added to return (synchronously) a
currently-unused TCP port integer. This can be used during app configuration
to decide on a listening port, which can then be passed into
`Tub.listenOn("tcp:%d" % portnum)`. This may allow Tub.setLocation() to be
called *before* the reactor is started, simplifying application startup code
(this also requires a suitable hostname or IP address, which is a separate
issue).
** Packaging/Dependency Changes
Foolscap now requires Twisted 10.1.0 or newer, to use Endpoints and
connection handler plugins.
Foolscap's logging system (specifically the twisted-to-foolscap bridge) is
now compatible with Twisted-15.2.0. The previous version had problems with
the new contents of twisted.logger's "eventDict" objects. (#235)
* Release 0.8.0 (15-Apr-2015)
** UnauthenticatedTub is gone
As announced in the previous release, UnauthenticatedTub has been removed.
All Tubs are fully authenticated now.
** Security Improvements
Foolscap now generates better TLS certificates, with 2048-bit RSA keys and
SHA256 digests. Previous versions used OpenSSL's defaults, which typically
meant 1024-bit MD5.
To benefit from the new certificates, you must regenerate your Tubs, which
means creating new FURLs (with new TubIDs). Previously-created Tubs will
continue to work normally: only new Tubs will be different.
** Packaging/Dependency Changes
setup.py now requires setuptools
Foolscap now requires pyOpenSSL unconditionally, because all Tubs are
authenticated.
We now recommend "pip install ." to install Foolscap and all its
dependencies, instead of "python setup.py install". See #231 for details.
* Release 0.7.0 (23-Sep-2014)
** Security Fixes
The "flappserver" feature was found to have a vulnerability in the
service-lookup code which, when combined with an attacker who has the ability
to write files to a location where the flappserver process could read them,
would allow that attacker to obtain control of the flappserver process.
Users who run flappservers should upgrade to 0.7.0, where this was fixed as
part of #226.
Each flappserver runs from a "base directory", and uses multiple files within
the basedir to track the services that have been configured. The format of
these files has changed. The flappserver tool in 0.7.0 remains capable of
reading the old format (safely), but will upgrade the basedir to the new
format when you use "flappserver add" to add a new service. Brand new
servers, created with "flappserver create", will use the new format.
The flappserver tool in 0.6.5 (or earlier) cannot handle this new format, and
will believe that no services have been configured. Therefore downgrading to
an older version of Foolscap will require manual reconstruction of the
configured services.
** Major Changes
UnauthenticatedTub has been deprecated, and will be removed in the next
release (0.8.0). This seldom-used feature provides Foolscap's RPC semantics
without any of the security, and was included to enable the use of Foolscap
without depending upon the (challenging-to-install) PyOpenSSL library.
However, in practice, the lack of a solid dependency on PyOpenSSL has made
installation more difficult for applications that *do* want the security, and
UnauthenticatedTub is a footgun waiting to go off. Foolscap's code and
packaging will be simpler without it. (#67)
** Minor Changes
The "git-foolscap" tools, which make it possible to publish and clone Git
repositories over a Foolscap (flappserver) connection, have been moved from
their hiding place in doc/examples/ into their own project, hosted at
https://github.com/warner/git-foolscap . They will also be published on PyPI,
to enable "pip install git-foolscap".
The documentation was converted from Lore to ReStructuredText (.rst). Thanks
to Koblaid for the patient work. (#148)
The connection-hint parser in 0.7.0 has been changed to handle all TCP forms
of Twisted's "Client Endpoint Descriptor" syntax, including the short
"tcp:127.0.0.1:9999" variant. A future version should handle arbitrary
endpoint descriptors (including Tor and i2p, see #203), but this small step
should improve forward compatibility. (#216, #217)
* Release 0.6.5 (12-Aug-2014)
** Compatibility Fixes
This release is compatible with Twisted-14.0.0.
Foolscap no longer claims compatability with python-2.4.x or 2.5.x . These
old versions might still work, but there are no longer automated tests to
ensure this. Future versions will almost certainly *not* work with anything
older than python-2.6.x . Foolscap remains incompatible with py3, sorry.
** Forward Compatibility
When parsing FURLs, the connection hints can now use TCP sockets described
with the Twisted Endpoints syntax (e.g. "tcp:host=127.0.0.1:port=9999"), in
addition to the earlier host:port "127.0.0.1:9999" form. Foolscap-0.6.5
ignores any hint that is not in one of these two forms. This should make it
easier to introduce new hint types in the future.
** Minor Changes
The "ChangeLog" file is no longer updated.
Violation reports now include the method name. (#201)
The "flappserver" tool explicitly rejects unicode input, rather than
producing hard-to-diagnose errors later. (#209)
* Release 0.6.4 (18-Jun-2012)
** Minor Changes
The unreliable 'extras_require' property in setup.py, which allowed other
python programs to declare a dependency on foolscap's "secure_connections"
feature, was removed. See README.packagers for alternate instructions. (#174)
'flogtool' log-dumping commands (dump, tail, web-viewer) now accept a
consistent --timestamps= argument to control how event times are displayed
(UTC, local, seconds-since-epoch, etc). (#192, #193)
Certain invalid "location" strings (accepted by Tub.setLocation and put into
FURLs) are rejected earlier, and with better error messages. The error
message produced when 'flogtool dump' is given a FURL-file (instead of an
event log file) has been improved.
The Incident Gatherer will tolerate incident-file errors better, fetching
remaining incidents instead of halting. (#190)
The git-over-foolscap tools were cleaned up, and the documentation was
brought into line with the implementation. (#197)
Other minor bugs were fixed: #179, #191, #194, #195, #196
pkgsrc.
* Release 0.6.3 (05-Jan-2012)
** Compatibility Fixes
This release really is compatible with Twisted-11.1.0 . The previous Foolscap
release (0.6.2), despite the changes described below, suffered mild
incompatibilites with the new TLS code in the final Twisted-11.1.0 release.
The most common symptom is a DirtyReactorError in unit tests that use
Tub.stopService() in their tearDown() method (to coordinate shutdown and
cleanup). Another symptom is tests overlapping with one another, causing
port-already-in-use errors.
This incompatibility did not generally affect normal operation, but only
impacted unit tests.
** Other Changes
The Debian packaging tools in misc/ were removed, as they were pretty stale.
These days, both Debian and Ubuntu make their own Foolscap packages.
* Release 0.6.2 (15-Oct-2011)
** Compatibility Fixes
Foolscap-0.6.2 will be compatible with future versions of Twisted (>11.0.0).
The 0.6.1 release will not: a TLS change went into Twisted trunk recently
(after the 11.0.0 release) which broke Foolscap 0.6.1 and earlier.
This release also fixes a minor incompatibility with newer versions of
OpenSSL (0.9.8o was ok, 1.0.0d was not), which caused errors in the test
suite (but normal runtime operation) on e.g. Ubuntu 11.10 "Oneiric".
** Git-Over-Foolscap Tools
The doc/examples/ directory contains two executables (git-foolscap and
git-remote-pb) which, when placed in your $PATH, make it easy to use Foolscap
to access a Git repository. These use the flappserver/flappclient tools and
let you build a FURL that provides read-only or read-write access to a single
repository. This is somewhat like providing SSH access to a repo, but with a
much smaller scope: the client will only be able to manipulate the one
repository, and gets no other authority on the target system. See the tool's
inline comments for usage instructions.
** Minor Fixes
Using 'flappserver upload-file FILE1 FILE2 FILE3..' (with three or more
files) now correctly uploads all files: previously it only managed to upload
the first and last.
'flappserver' argument handling was improved slightly. A workaround was added
to handle a Twisted stdio-closing bug which affected flappserver's
run-command function and broke the git-foolscap tool. Several changes were
made for the benefit of Windows: log filenames all use hyphens (not colons),
log filtering tools tolerate the lack of atomic-rename filesystem operations,
and some unixisms in the test suite were removed.
The Tub.setLogGathererFURL() method can now accept a list (iterable) of log
gatherer FURLs, not just a single one.
require this.
* Release 0.6.1 (16-Jan-2011)
** Minor Fixes
The old "sets" module is no longer imported without wrapping the import in a
DeprecationWarning suppressor. We still import it from slicers.set for
compatibility with older code, but that import will not produce a warning.
This should make Foolscap quieter when used with Python 2.6 or later.
A new RemoteReference method named getDataLastReceivedAt() was added, which
will tell you when data was most recently received on the connection
supporting that reference. This can be compared against time.time() to see
how "live" the connection is. For performance reasons, this is only enabled
when keepalives are turned on, otherwise it returns None. (#169)
Some unreachable code was removed. (#165)
* Release 0.6.0 (28-Dec-2010)
** API Changes
*** "foolscap.api" now mandatory
The old import names from foolscap/__init__.py have been removed, finishing
the transition begun with 0.5.0 . Applications must now import Tub,
Referenceable, and so on from "foolscap.api". (#122)
** Compatibility Fixes
Foolscap-0.6.0 is compatible with Twisted-10.2 (released 29-Nov-2010). The
0.5.1 release was not: pb.Listener was depending upon the behavior of an
internal Twisted function that changed, causing an AttributeError in
"StreamServerEndpointService". This is fixed, but the code is still using an
undocumented internal attribute to handle port=0 which will need to be
replaced eventually. (#167)
The first unit test ("test__versions") spuriously failed against Twisted-10.1
and 10.2, mistakenly believing that 10.1 was older than 8.1.0 due to a
lexicographic comparison that should have been numeric.
** Other Changes
Incident filenames are now like "2008-08-22--16:20:28Z.flog" which are in UTC
and mostly ISO-8601 format (the real ISO-8601 would use "_" instead of "--").
This is also used for log-gatherer filenames. (#111)
The logging code now honors FLOGLEVEL= when using FLOGTOTWISTED=1; previously
FLOGLEVEL= was ignored when deciding which log events should be bridged to
the twisted logger. (#154)
Some minor packaging bugs were fixed.
This is a ground-up rewrite of Perspective Broker, which itself is Twisted's
native RPC/RMI protocol (Remote Procedure Call / Remote Method Invocation).
If you have control of both ends of the wire, and are thus not constrained to
use some other protocol like HTTP/XMLRPC/CORBA/etc, you might consider using
Foolscap.
Fundamentally, Foolscap allows you to make a python object in one process
available to code in other processes, which means you can invoke its methods
remotely. This includes a data serialization layer to convey the object
graphs for the arguments and the eventual response, and an object reference
system to keep track of which objects you are connecting to. It uses a
capability-based security model, such that once you create a non-public
object, it is only accessible to clients to whom you've given the
(unguessable) FURL. You can of course publish world-visible objects that
have well-known FURLs.
