Free interprocess software for linux

SpoonRPC is a python module that provides a distributed communication system for interprocess communication. The project doesnt actually provide RPC at the moment, because message passing turned out to be a lot easier, and probably more useful anyway.
Main features:
- Safe, efficient object serialization with ASN.1 BER
- Simple, easy messaging between nodes
- Message routing
- Transport agnostic, just needs a stream of some kind.
- Can create ad-hoc networks of nodes with multiple links for reliability
- Licensed under the MIT license.
poonRPC provides the ability to connect many different processes together and send messages between them. The processes can be running across any number of hosts. Security is up to the implementation, but by using SSL or paramiko adding a layer of security is easy.
A message consists of a string to identify the message type, and an arbitrary object attachment. Messages can be dispatched, by the message type, to functions by using a decorator. Arbitrary python objects are serialized using BER, however only the data members of the object are serialized. Code cannot be serialized, this is a feature, not an oversight. Each process must have a copy of the class for the objects serialized.
Each node has one or more links to other nodes which forms a larger network of nodes. Messages are routed using a dynamic routing algorithm, the most efficient route is chosen as nodes and links come and go. This allows nodes that do not have a direct connection between eachother to communicate.

IPC::PubSub is Perl module for Interprocess Publish/Subscribe channels.

SYNOPSIS

# A new message bus with the DBM::Deep backend
# (Other possible backends include Memcached and PlainHash)
my $bus = IPC::PubSub->new(DBM_Deep => /tmp/pubsub.db);

# A channel is any arbitrary string
my $channel = #perl6;

# Register a new publisher (you can publish to multiple channels)
my $pub = $bus->new_publisher("#perl6", "#moose");

# Publish a message (may be a complex object) to those channels
$pub->msg("This is a message");

# Register a new subscriber (you can subscribe to multiple channels)
my $sub = $bus->new_subscriber("#moose");

# Publish an object to channels
$pub->msg("This is another message");

# Set all subsequent messages from this publisher to expire in 30 seconds
$pub->expiry(30);
$pub->msg("This message will go away in 30 seconds");

# Simple get: Returns the messages sent since the previous get,
# but only for the first channel.
my @msgs = $sub->get;

# Simple get, with an explicit channel key (must be among the ones
# it initially subscribed to)
my @moose_msgs = $sub->get("#moose");

# Complex get: Returns a hash reference from channels to array
# references of [timestamp, message].
my $hash_ref = $sub->get_all;

# Changing the list of channels we subscribe to
$sub->subscribe(some-other-channel);
$sub->unsubscribe(some-other-channel);

# Changing the list of channels we publish to
$pub->publish(some-other-channel);
$pub->unpublish(some-other-channel);

# Listing and checking if we are in a channel
my @sub_channels = $sub->channels;
my @pub_channels = $pub->channels;
print "Sub is in #moose" if $sub->channels->{#moose};
print "Pub is in #moose" if $pub->channels->{#moose};

# Raw cache manipulation APIs (not advised; use ->modify instead)
$bus->lock(channel);
$bus->unlock(channel);
my @timed_msgs = $bus->fetch(key1, key2, key3);
$bus->store(key, value, time, 30);

# Atomic updating of cache content; $_ is stored back on the
# end of the callback.
my $rv = $bus->modify(key => sub { delete $_->{foo} });

# Shorthand for $bus->modify(key => sub { $_ = val });
$bus->modify(key => val);

# Shorthand for $bus->modify(key => sub { $_ });
$bus->modify(key);

This module provides a simple API for publishing messages to channels and for subscribing to them.

When a message is published on a channel, all subscribers currently in that channel will get it on their next get or get_all call.

Currently, it offers three backends: DBM_Deep for on-disk storage, Memcached for possibly multi-host storage, and PlainHash for single-process storage.

Please see the tests in t/ for this distribution, as well as "SYNOPSIS" above, for some usage examples; detailed documentation is not yet available.

Joshs Website Framework is a CMS framework for PHP Web developers. Joshs Website Framework consists of various subcomponents you can extract and use individually. SaxInterface provides an OO wrapper for SAX XML parsing.

The Auth Engine provides both level-based permissions (e.g., must be level 100 to access this page) and name-based permissions (e.g., must be in "editor" group to access this page).

Utilities include Mutex and SharedData classes (for interprocess communication), site-wide custom error handling, and the ability to take a site offline for maintenance.

IPC::LDT is a Perl module that implements a length based IPC protocol.

Interprocess communication often uses line (or record) oriented protocols. FTP, for example, usually is such a protocol: a client sends a command (e.g. "LS") which is completed by a carriage return. This carriage return is included in the command which is sent to the server process (FTP deamon) which could implement its reading in a way like this:

while ($cmd= )
{
chomp($cmd);
performCommand($cmd);
}

Well, such record oriented, blocked protocols are very useful and simply to implement, but sometimes there is a need to transfer more complex data which has no trailing carriage return, or data which may include more carriage returns inside the message which should not cause the reciepient to think the message is already complete while it is really not. Even if you choose to replace carriage returns by some obscure delimiters, the same could happen again until you switch to a protocol which does not flag the end of a message by special strings.
On the other hand, if there is no final carriage return (or whatever flag string) within a message, the end of the message has to be marked another way to avoid blocking by endless waiting for more message parts. A simple way to provide this is to precede a message by a prefix which includes the length of the remaining (real) message. A reciepient reads this prefix, decodes the length information and continues reading until the announced number of bytes came in.

IPC::LDT provides a class to build objects which transparently perform such "length driven transfer". A user sends and receives messages by simple method calls, while the LDT objects perform the complete translation into and from LDT messages (with prefix) and all the necessary low level IO handling to transfer stream messages on non blocked handles.

IPC::LDT objects can be configured to transfer simle string messages as well as complex data structures. Additionally, they allow to delay the transfer of certain messages in a user defined way.

Streams is an I/O library designed to eventually replace the current I/O facilities based on using Handles. The main advantage is its strong modular design using typeclasses. It consists of small independent modules, each implementing one type of stream (file, memory buffer, pipe, etc.) or one part of common stream functionality (buffering, char encoding, locking, etc.).

3rd-party librarie can easily add new stream types and new common functionality. Other benefits of the new library include support for streams functioning in any monad, Hugs and GHC compatibility, high speed, and an easy migration path from the existing I/O library. It is heavily based on the HVIO module written by John Goerzen.

Simple Streams

The key concept of the lib is the Stream class, whose interface mimics familiar interface for Handles, just with "h" replaced with "v" in function names:

class (Monad m) => Stream m h where
vPutStrLn :: h -> String -> m ()
vGetContents :: h -> m String
vIsEOF :: h -> m Bool
vClose :: h -> m ()
....................

This means that you already know how to use any stream! The Stream interface currently has 8 implementations: a Handle itself, raw files, pipes, memory buffers and string buffers. Future plans include support for memory-mapped files, sockets, circular memory buffers for interprocess communication and UArray-based streams.
By themselves, these Stream implementations are rather simple.

Basically, to implement new Stream type, its enough to provide vPutBuf/vGetBuf operations, or even vGetChar/vPutChar. The latter way, although inefficient, allows us to implement streams that can work in any monad. StringReader and StringBuffer streams use this to provide string-based Stream class implementations both for IO and ST monads. Yes, you can use the full power of Stream operations inside the ST monad!

CMU Common Lisp is a free implementation of the Common Lisp programming language which runs on most major Unix platforms. CMU Common Lisp project mainly conforms to the ANSI Common Lisp standard.
Main features:
- a sophisticated native-code compiler which is capable of powerful type inferences, and generates code competitive in speed with C compilers.
- generational garbage collection and multiprocessing capability on the x86 ports.
- a foreign function interface which allows interfacing with C code and system libraries, including shared libraries on most platforms, and direct access to Unix system calls.
- support for interprocess communication and remote procedure calls.
- an implementation of CLOS, the Common Lisp Object System, which includes multimethods and a metaobject protocol.
- a graphical source-level debugger using a Motif interface, and a code profiler.
- an interface to the X11 Window System (CLX), and a sophisticated graphical widget library (Garnet).
- programmer-extensible input and output streams.
- an Emacs-like editor implemented in Common Lisp.
- freely redistributable: free, with full source code (most of which is in the public domain) and no strings attached (and no warranty). Like the GNU/Linux and *BSD operating systems, CMUCL is maintained and improved by a team of volunteers collaborating over the Internet.
Common Lisp is well suited to large programming projects and explorative programming. The language has a dynamic semantics which distinguishes it from languages such as C and Ada.
It features automatic memory management, an interactive incremental development environment, a module system, a large number of powerful data structures, a large standard library of useful functions, a sophisticated object system supporting multiple inheritance and generic functions, an exception system, user-defined types and a macro system which allows programmers to extend the language.
Enhancements:
- A new float type EXT:DOUBLE-DOUBLE-FLOAT is supported.
- A DOUBLE-DOUBLE-FLOAT uses two DOUBLE-FLOATs to represent a number with >= 106 bits of precision (about 33 digits).
- Hash tables now support weak value, weak key- and-value, and weak key-or-value tables.
- LONG-LONG and UNSIGNED-LONG-LONG are recognized types in the C-CALL package for signed and unsigned 64-bit integers.
- The generational garbage collector has been ported to Darwin/ PPC.
- Numerous bugs and ANSI-compliance problems have been fixed.