summaryrefslogtreecommitdiff
path: root/net/py-foolscap
AgeCommit message (Collapse)AuthorFilesLines
2014-05-09Mark packages that are not ready for python-3.3 also not ready for 3.4,wiz1-2/+2
until proven otherwise.
2014-01-25Mark packages as not ready for python-3.x where applicable;wiz1-2/+3
either because they themselves are not ready or because a dependency isn't. This is annotated by PYTHON_VERSIONS_INCOMPATIBLE= 33 # not yet ported as of x.y.z or PYTHON_VERSIONS_INCOMPATIBLE= 33 # py-foo, py-bar respectively, please use the same style for other packages, and check during updates. Use versioned_dependencies.mk where applicable. Use REPLACE_PYTHON instead of handcoded alternatives, where applicable. Reorder Makefile sections into standard order, where applicable. Remove PYTHON_VERSIONS_INCLUDE_3X lines since that will be default with the next commit. Whitespace cleanups and other nits corrected, where necessary.
2012-10-23Drop superfluous PKG_DESTDIR_SUPPORT, "user-destdir" is default these days.asau1-3/+1
2012-10-04Remove unnecessary python restriction (to all supported versions).wiz1-4/+1
2012-08-21Update to 0.6.4.gdt2-6/+6
* 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
2012-05-25Update to 0.6.3. Note that 0.6.1 really does not work with Twisted ingdt3-7/+11
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.
2011-02-25Let's assume for now that everything that worked with python-2.6 alsowiz1-2/+2
works with python-2.7.
2011-01-29Clean up DISTNAME (remove .tar, move into extract suffix). Dropgdt1-5/+5
EGG_NAME and EXTRACT_SUFX because they are now default. Add TEST_TARGET. Add comment questioning why PYTHON_VERSIONS_ACCEPTED is only 26.
2011-01-29Update to 0.6.1, triggered by pending tahoe-lafs 1.8.2 which willgdt3-12/+9
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.
2010-07-23Import py26-foolscap-0.5.1 as net/py-foolscap.gdt4-0/+343
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.