Free subscriber software for linux

Requirements:

• Python

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.

Number::Phone::IE is a Perl module with Republic of Ireland-specific methods for Number::Phone.
SYNOPSIS
use Number::Phone;
$dermots_phone = Number::Phone->new(IE, 017654321);
METHODS
The following methods from Number::Phone are overridden:
is_valid
The number is valid within the national numbering scheme. It may or may not yet be allocated, or it may be reserved. Any number which returns true for any of the following methods will also be valid.
is_allocated
The number has been allocated to a telco for use. It may or may not yet be in use or may be reserved. Not currently implemented.
is_geographic
The number refers to a geographic area.
is_fixed_line
The number, when in use, can only refer to a fixed line.
is_mobile
The number, when in use, can only refer to a mobile phone.
is_pager
The number, when in use, can only refer to a pager.
is_tollfree
Callers will not be charged for calls to this number under normal circumstances.
is_specialrate
The number, when in use, attracts special rates. For instance, national dialling at local rates, or premium rates for services.
is_adult
The number, when in use, goes to a service of an adult nature, such as porn.
is_network_service
The number is some kind of network service such as a human operator, directory enquiries, emergency services etc
country_code
Returns 353.
regulator
Returns some text in an appropriate character set saying who the telecoms regulator is, with optional details such as their web site or phone number.
areacode
Return the area code - if applicable - for the number. If not applicable, returns undef.
areaname
Return the area name - if applicable - for the number, or undef.
subscriber
Return the subscriber part of the number
operator
Return the name of the telco operating this number, in an appropriate character set and with optional details such as their web site or phone number. Not currently implemented.
format
Return a sanely formatted version of the number, complete with IDD code, eg for the Irish number (021) 765-4321 it would return +353 21 7654321.
country
If the number is_international, return the two-letter ISO country code.
NYI
Version restrictions:
- Strictly sppeaking, this kind of duplication of the Number::Phone::UK class is bad. A tidy-up is in order, though it may emerge that a completely new implemantation is better.
- The results are only as accurate as my own investigations into current allocations. User feedback welcome.
- While the names of the nominal owners of mobile prefixes are given, number portability makes this information unreliable.

SipExchange is an open-source softswitch that provides standard SIP services like registration, presence and proxy. Using the SipExchange application, service providers can offer telephone services to their subscribers as well as other services based on voice, video and instant messaging.
SipExchange supports many of the standard subscriber features offered by the traditional telephone exchanges and PBXs. In addition, SipExchange supports external call control capabilities using which service providers and software developers can create new features and services rapidly and plug them into the SipExchange application.
SipExchange works with standard SIP phones that adhere to the SIP protocol standards.
SipExchange leverages the Java and J2EE technology as a basis for the architecture that is flexible, scalable and easily extensible. It runs as an enterprise application inside the JBoss server and takes advantage of many services that a J2EE server provides.
SipExchange provides a web-based user interface using which system administrators can manage subscribers and features as well as perform other routine operations. SipExchange also provides a web-based user interface using which subscribers can customize the features they have subscribed to.
Enhancements:
- SipExchange is now developed using the EJB3 architecture.
- The EJB3 architecture is the latest J2EE specification for enterprise application development.
- Although the end user does not see any difference, it is now much easier to develop back-end business logic because of this new technology.
- In addition, initial (experimental) support for Web services was added.
- The automated unit tests have been revamped.
- A number of bugs have been fixed.

Audio::LADSPA::Network is a semi automatic connection of Audio::LADSPA::* objects.

SYNOPSIS

use Audio::LADSPA::Network;
use Audio::LADSPA::Plugin::Play;
sub subscriber {
my ($object,$event) = @_;
$object = ref($object);
print "Recieved event $event from $objectn";
}
Audio::LADSPA::Network->add_subscriber(*,⊂scriber);

my $net = Audio::LADSPA::Network->new();
my $sine = $net->add_plugin( label => sine_fcac );
my $delay = $net->add_plugin( label => delay_5s );
my $play = $net->add_plugin(Audio::LADSPA::Plugin::Play);

$net->connect($sine,Output,$delay,Input);
$net->connect($delay,Output,$play,Input);

$sine->set(Frequency (Hz) => 440); # set freq
$sine->set(Amplitude => 1); # set amp

$delay->set(Delay (Seconds) => 1); # 1 sec delay
$delay->set(Dry/Wet Balance => 0.2); # balance - 0.2

for ( 0 .. 100 ) {
$net->run(100);
}
$sine->set(Amplitude => 0); #just delay from now
for ( 0 .. 500 ) {
$net->run(100);
}

This module makes it easier to create connecting Audio::LADSPA::Plugin objects. It automatically keeps the sampling frequencies correct for all plugins, adds control and audio buffers to unconnected plugins and prevents illegal connections.

It also implements an observable-type API via Class::Publisher that can be used to recieve notifications of events in the network. Amongst other things, this makes writing loosely coupled GUIs fairly straightforward.

The Project Logger provides a simple yet effective means for keeping people informed about the progress of projects, itineraries, or any sort of plans.

It combines the simplicity of blogging with dates, tasks, files, costs, and RSS feed modules to form a central broadcast point from which to keep people coordinated. How many times have problems occurred because of "I didnt know" or "I was unaware" or "When the #$% did that happen?"

The Project Logger solves this problem by making a tool that is first and foremost simple to use both from a publisher (how easy is it to enter information?) and from a subscriber (How easy is it to get to the information?) standpoint.

Slauth is a Perl-based authentication and authorization module for Apache HTTPD 2. Slauth project has a plugin architecture. The main plugin initially available allows subscribers of specific Mailman mail lists to self-register for authenticated web site access.

This code has been in operation since Spring 2004. But documentation is currently needed.

HISTORY

Slauth was originally developed for use by Stratofox, an amateur aerospace tracking and recovery team. (Sometimes this has also been called "nearspacecraft hunting".)

The ability to have users self-register based on Mailman mail list subscriptions resulted mostly from discussions with two rocket-building groups that Stratofox works with. The rocket-builders parted paths and didnt want each others private information available to the other. At the time both were nearly ready to attmept the first non-government space launch. After some discussion, this capability was developed by Stratofox during the search for an acceptable method to continue to
work with both groups and continue to participate in their launches.

INSTALLATION

Note: instead of using ExtUtils::MakeMaker, the installation process is based on Module::Build (which is intended to supersede it.) The process is similar, using Build.PL instead of Makefile.PL and our own generated Build script (made by Build.PL) instead of your systems make command.

To install this module type the following:

perl Build.PL
Build
Build test
Build install

Multi-Simulator Interface, in shrot MSI, is a simulation interconnection engine. In other words it is a program that connects simulations together by synchronizing their clocks and data. Multi-Simulation Interface serves the same purpose as HLA and supports most of HLAs functionality (and more).
The MSI is an HLA alternative. The major motivating factors in the design of the MSI are speed, interoperability, and ease of use.
The MSI was written as a cutting edge distributed simulation component to connect multiple instances of ATLs premiere simulation software, CSIM, and it can be used to interface any compatible simulations.
How does the MSI compare to HLA?
The MSI was originally created to be just a light weight HLA RTI. However, as it was written, limitations in HLA were discovered. The MSI is an improvement on both the design and implementation of HLA. Some highlights include:
A 1,536 to 1 reduction in size over the publicly available (until late 2002) HLA RTI.
At least one order of magnitude of bandwidth consumption less than the publicly available (until late 2002) HLA RTI.
The ability to subscribe to an object name in addition to a type.
Time synchronization that allows for proper causality when used with discrete event simulators.
Support for systems-of-systems (SoS) and hierarchically organized simulations.
Availability for many platforms.
MSI Concept - A Synchronized Data Broker
The concept behind MSI is the synchronized data broker. There are many connected software systems that posses state data that changes over the life of that system. In the case where these systems need to exchange this changing data with other systems and the other systems will exhibit the effects of this data on their own state, the synchronization of this data may need to be managed.
Historically the management of this data has been as simple as tagging it with the time of its release. If there is any conflict in the data the most recent version of the data is used. If the data is late an extrapolation can potentially be used. In SQL relational databases transactions and locking are used to ensure data integrity. Most data brokering services offer little or no sychronization, only delivery.
MSI Setup and Use
The MSI uses a XML stream through a direct socket connection for communications. This enables the MSI to be used from any programming language that can use sockets (C, C++, Java, Ada, Lisp, Perl, etc.). Also, the MSI was written with cross-platform libraries that make it portable to all the major OS platforms (Linux, Solaris, Mac OS X, Microsoft Windows, IRIX, HPUX, etc.).
The MSI is a single executable file and is distributed with example code for the simulator/federate side interface.
MSI Time Synchronization
The MSI time synchronizer can mix unconstrained with time constrained simulations. Each constrained simulation reports the time of the next event that will occur in that simulation/federate. This time may be artificially inflated to cause loose synchronization (less overhead but less guarantee of accuracy). The simulations/federates will advance to the announced time.
MSI Data Synchronization
The MSI implements a publish/subscribe data broker. The MSI is presently not validating, therefore it does not require a separate data format specification (like the HLA FOM). When data format validation is implemented, it will be an optional feature and not written in Lisp. This greatly reduces MSIs setup time. Also, not being locked to a predetermined data format allows for dynamic data types.
There are five commands associated with the MSI data broker: publish, subscribe, update, unsubscribe, destroy (destroy is not implemented yet). Simulations/federates may subscribe to object names in addition to object types. This allows simulations to subscribe to specific objects of a type without needing to receive updates of all objects of that type. The update command is both an incoming and outgoing command. When a simulation/federate receives an update command, it is expected to reflect the new values of that object.
The MSI has a very flexible publish and subscribe system. A federate may subscribe to an object type or an object name. In addition a federate may specify particular attributes of an object or object type. For example, if an object has attributes name, x, y, and z, a federate that only considers two dimensions may choose to subscribe only to name, x, and y.
The MSI also supports systems of systems and object hierarchy in simulations. A publishing federate may designate a parent object. Subscribers may then subscribe to the objects children.
MSI Messaging
The MSI allows simulations/federates to send messages (interactions in HLA) to each other. These messages can contain multiple attributes and be multicast to a specific group of simulations.
Recently Added Features
Removed external library dependencies to improve the portability and fragility of the MSI.
Added a better client library.
Improved documentation.
Enhancements:
- An XML parsing bug in the utilities library was fixed.
- The socket library was enhanced with more protocols, Win32 tricks, and the ability to key off of addresses as well as names.
- The --wait-for command line argument was added.
- Several internal bugs were fixed.
- More of the client library and the CSIM interface were flushed out.
- All standard functionality was tested.