Revision 1.8, Wed Sep 30 19:24:35 2015 UTC (8 years, 6 months ago) by wiz
Branch: MAIN
Changes since 1.7: +4 -4 lines

Update to 0.9.1:

* 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)