Free interprocess publish software for linux

Libtubo Interprocess Communication is a small and simple library that can run processes in the background and communicate via the stdout, stderr, and stdin file descriptors.
The functionality of libtubo is similar to the glib function g_spawn_async_with_pipes(), except that all pipe setup and monitoring is taken care of.
The calling function only has to provide the functions with which to process the input/output of the remote process.
The library first appeared in the year 2000 in the xfce3 desktop as part of the xfsamba application, and is now available for use for other developers.
Enhancements:
- Some control bugfixes.
- The version has been updated to the xffm scheme, as this package is now distributed with xffm.

eZ publish is a popular open source content management system and development framework. eZ publish project is distributed, developed and supported by eZ systems. eZ systems is a commercial company, founded by experienced and open-minded people. The company builds its business by providing services around the eZ publish system. For more information about eZ systems, read the "What is eZ systems?" section.
eZ publish allows the development of highly professional and customized internet solutions and dynamic web applications. It can be used to build anything from a personal homepage to a multinational corporate website with role based multiuser access, online shopping, discussion forums and other advanced functionality. In addition, because of its nature of openness, eZ publish can be easily plugged into, communicate and coexist with existing IT-solutions.
eZ publish comes with a wide range of advanced built-in features, which make it possible to develop professional, complex, secure and reliable solutions within a short amount of time. In addition to the built-in features, the system allows for extensions and custom modifications in almost any direction. Unlike other content management systems, eZ publish delivers a flexible, generic solution with very few limitations. In other words, this is a scalable and dynamic system that companies and organizations can grow with.
eZ publish is platform independent. It can be used on Windows and several UNIX variants such as OS X, Linux, FreeBSD, Solaris, IRIX, etc. In addition, eZ publish is also database independent; if a specific database isnt supported, it is possible to write a driver without modifying any kernel code.
eZ publish is open software, supporting open standards. The software is constructed following strict development processes in order to ensure high technical quality and usability.
eZ publish is dual licensed. There is a GPL (General Public License) and a professional license. Using the GPL license, people can build their own open source applications and thereby contribute to the development of free and open software. The professional license allows companies to make and sell commercial software that is developed using and/or built upon the eZ publish system.
Enhancements:
- Several bugfixes and enhancements.
- The command line package tool ezpm.php has been updated: list, import, and install commands have been changed to match the admin interface functionality.
- The ezinstallscript and ezextension items are supported by the add command. ezpm is allowed to set the vendor.
- Enhancement #010347 (progress output for correctxmltext.php and updatetypedrelation.php) has been implemented.

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.

GnuPG::Interface is a Perl interface to GnuPG.

SYNOPSIS

# A simple example
use IO::Handle;
use GnuPG::Interface;

# settting up the situation
my $gnupg = GnuPG::Interface->new();
$gnupg->options->hash_init( armor => 1,
homedir => /home/foobar );

# Note you can set the recipients even if you arent encrypting!
$gnupg->options->push_recipients( ftobin@cpan.org );
$gnupg->options->meta_interactive( 0 );

# how we create some handles to interact with GnuPG
my $input = IO::Handle->new();
my $output = IO::Handle->new();
my $handles = GnuPG::Handles->new( stdin => $input,
stdout => $output );

# Now well go about encrypting with the options already set
my @plaintext = ( foobar );
my $pid = $gnupg->encrypt( handles => $handles );

# Now we write to the input of GnuPG
print $input @plaintext;
close $input;

# now we read the output
my @ciphertext = ;
close $output;

waitpid $pid, 0;

GnuPG::Interface and its associated modules are designed to provide an object-oriented method for interacting with GnuPG, being able to perform functions such as but not limited to encrypting, signing, decryption, verification, and key-listing parsing.

How Data Member Accessor Methods are Created

Each module in the GnuPG::Interface bundle relies on Class::MethodMaker to generate the get/set methods used to set the objects data members. This is very important to realize. This means that any data member which is a list has special methods assigned to it for pushing, popping, and clearing the list.

Understanding Bidirectional Communication

It is also imperative to realize that this package uses interprocess communication methods similar to those used in IPC::Open3 and "Bidirectional Communication with Another Process" in perlipc, and that users of this package need to understand how to use this method because this package does not abstract these methods for the user greatly. This package is not designed to abstract this away entirely (partly for security purposes), but rather to simply help create proper, clean calls to GnuPG, and to implement key-listing parsing. Please see "Bidirectional Communication with Another Process" in perlipc to learn how to deal with these methods.

Using this package to do message processing generally invovlves creating a GnuPG::Interface object, creating a GnuPG::Handles object, setting some options in its options data member, and then calling a method which invokes GnuPG, such as clearsign. One then interacts with with the handles appropriately, as described in "Bidirectional Communication with Another Process" in perlipc.

INews is a system to write and publish newspapers on the internet.

INews is different, because:

* the newspaper has a traditional structure, with pages and articles distributed like in a paper newspaper.
* the newspaper is not published using HTML, but can be read with a java application.

INews is a complete system, composed by:

* a server application.
* an editor application, to write and publish editions of the newspaper.
* a reader application, to read the last edition of the newspaper on the internet.
* an administration application.

Purposes of the system are:

* speed and simplicity to write and publish the newspaper:
if the articles are ready as RTF documents (written with the most common word processors) and the pictures are ready, it should be a matter of minutes to publish the newspaper.
* to work in team to publish the newspaper.
* to keep an archive with all the articles, images and editions of the newspaper.
* to be open: all the articles and images are saved in the filesystem in a directory tree.

It is possible to build new parts types (like articles and images) and add them to the system.

iogen is an I/O generator. iogen forks child processes that each run a mix of reads and writes. The idea is to generate heavily fragmented files to make the hardware suffer as much as possible.
This tool has been used to test filesystems, drivers, firmware, and hardware devices. It is by no means meant as a performance measuring tool since it tries to recreate the worst case scenario I/O.
This code was developed and tested on OpenBSD 3.8-current Dec 6 2005. This code should be POSIX compliant and therefore should compile on all well behaving UNIXi. If you are inclined to port this to another OS send me a diff and if it is good Ill merge it with the actual code.
Please note that I will not generate additional makefiles besides the example in the current version. The official Makefile is part of the OpenBSD ports tree and is non-portable. I will publish, ONLY under a BSD license, makefiles and diffs that enable iogen to run on other OSs on this website.
Enhancements:
- The Linux makefile was fixed.

THREDDS (short from Thematic Realtime Environmental Distributed Data Services) project is developing middleware to bridge the gap between data providers and data users. The goal is to simplify the discovery and use of scientific data and to allow scientific publications and educational materials to reference scientific data.

The mission of THREDDS is for students, educators and researchers to publish, contribute, find, and interact with data relating to the Earth system in a convenient, effective, and integrated fashion.

Just as the World Wide Web and digital library technologies have simplified the process of publishing and accessing multimedia documents, THREDDS is building infrastructure needed for publishing and accessing scientific data in a similarly convenient fashion.

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.