Overview

Rapid and cheap development dictates use of readily available components glued together.

These notes suggest strategies for minimizing rework when later optimizing performance and quality.

Python

Python is an optimal glue and rapid prototyping language and is likely to provide adequate long term performance by simply wrapping C/C++ libraries - eg using Boost.Python

at only those "hotspots" where performance improvement is actually proved necessary through testing. For this reason Python performance is superior to Java and comparable to C. The more important fact is that Python development is faster and maintenance and evolution easier.

 

The file system (including message queues/pipes) is the most straight forward way of interfacing between components - especially for low power and therefore memory constrained deployments.

 

A highly scalable and evolvable asynchronous store and forward messaging queues "publish and subscribe" architectural orientation is central to most aspects. Python is well suited to such development.

 

At larger central hubs with multiple internet connections, directory services etc, concurrency issues are best handled using database components such as Postgresql. Python is well suited for database development eg with SQLalchemy and can even be used as a procedural language for stored procedures, triggers etc within Postgresql servers.

Java

Some readily available components are likely to require deployment of Java Runtime Environment.

For example some prototype software for Postmanet supplies relevant Java APIs that could be adapted for postal area links via DVD and flash. Initial proof of concept might use subsets (supertypes) of these APIs to support protected variation for evolution.

Careful consideration should be given to interaction with routing protocols for Delay Tolerant Networking where existing work for the bundle protocol DTN2 is done in C/C++. See also N4C EU project for communications challenged communities.

To avoid getting sucked into Java development and stick to Python as primary project language, such adaptors should be written in Jython and communicate with other components primarily via the file system. This could simplify any subsequent conversion to cPython.

There are also some possibilities that lighter weight versions of Java may end up usable for deployment on resource constrained hardware.

Examples include:

Sun's Micro Edition for mobile and embedded applications.

Something like this form of Trace-Driven JIT compilation

Perl

Perl is unreadable and therefore unmaintainable and should be avoided like the plague.

Unfortunately some readily available tools for interfacing with likely major system components like the INN net news server use Perl.

There is some hope that Parrot may enable postponing conversion. But assume any such use of Perl will eventually be replaced.

Windows

It is necessary to support end users (including content providers) with existing Windows PCs and therefore to clearly separate any platform specific components from cross platform ones and select cross platform techniques wherever feasible.

 

An important issue is that existing "leaf" internet connected PCs at the boundary of the postal media network are likely to be Windows PCs.

 

What we mainly need from them is their internet connection to attach to a postal "hub". If they also have a CD/DVD writer (as opposed to player) that can be used by the hub, some additional cost savings could be achieved by also using that.

 

For proof of concept and initial deployment it is probably simplest to just put a small appliance box between the internet connection and the PC. The additional boxes could later be redeployed elsewhere if another solution becomes viable (which is unlikely).

 

For proof of concept the boxes would initially have their own external USB DVD writers. It may well be feasible for them to use the Windows PC DVD writer for deployment. Implementing the necessary software should be deferred until cost justified as any DVD writers deployed while it is unavailable can simply be redeployed when it becomes available.

 

For proof of concept the boxes would initially have their own external USB mass storage. The same considerations apply as for DVD writers.

 

Essentially all we should focus on is sharing the internet connection.

Macintosh

It is also necessary to support Mac OS X end users, but less important than for Windows as there will be far less of them. The same considerations apply as for Windows but will be easier to implement due to the underlying BSD unix Darwin operating system on Mac OS X.

 

Unfinished

This page, like all the others is unfinished. There is an overwhelming amount of information to absorb and digest for an inception phase.