Jul 1992 - Sep 1998. EDIPOST Project

Australia Post had developed a B20 system which allowed customers to electronically lodge telegrams. The system was very successful, but could only handle small message volumes.

I joined the project as a Unix specialist to lead the development of a high volume "hybrid mail" system. A hybrid mail system accepts documents electronically, then electronically routes those documents to production centres so they can be printed and enveloped for delivery via the physical mail network.

In the first six months with the project, I developed the EDIPOST prototype using the GNU C compiler. The prototype had a Motif GUI which was implemented via WCL (Widget Creation Library). This prototype proved to be so flexible and useful that Australia Post put it directly into production. To minimise the amount of support code needed in the application, all configuration was via flat text files which are loaded using Yacc and Lex grammars.

The system was developed and installed (and still runs in production) on Sun Sparc 10 systems using SunOS 4.1. All of the initial software installation and configuration on the Sun workstations was performed by me. This included configuring, compiling, and installing tools such as GCC, GNU Make, Bison, Flex, Emacs, Sendmail, etc.

The EDIPOST system was targeted to capture the high end of the hybrid mail market where customers would submit jobs of upwards of 100,000 documents. As more customers were brought onto EDIPOST I enhanced the system to provide extra processing capabilities required to win business. Enough printers were installed on the national EDIPOST WAN to handle a peak production of over 1,000,000 documents per day. At this point, the system had around 40,000 lines of C.

To accommodate more complicated customer jobs, I added a macro code facility for assisting in the print/merge process. The macro code syntax was designed to look like C as this was the language most familiar to the people bringing customers on to the system.

A curses debugging interface was developed to allow developers to step through the bytecodes created by the macro code interpreter.

I developed an experimental user interface in Tcl/Tk to replace the Motif user interface. Due to time constraints, this was not taken any further.

The EDIPOST system currently produces more than 100 different customer document types including electricity bills, water bills, council rates notices, bank statements, and "easy pay" voucher booklets.

The EDIPOST system and the Australia Post Agency system have been joined together to provide a complete solution where large customers can electronically submit their raw billing run data to EDIPOST. EDIPOST then formats, prints and delivers the bills as physical mail. These bills can then be paid over the counter at any Post Office via the Agency System. The customer then receives all payments of their bills electronically.

When Linux 0.98 was released, I retrieved the SLS Linux distribution and installed that on a PC to use as my workstation.

Early in 1994, representatives from a Danish company called International Data Post (IDP) visited Australia with the intention of selling their hybrid mail system to Australia Post. After seeing EDIPOST, instead of selling Australia Post their product, IDP decided to buy the resale rights to the EDIPOST system.

Part of the deal between Australia Post and International Data Post involved me going to Denmark to assist in the formulation of the requirements for the next generation hybrid mail system.

While I was there, I also specified the changes that were necessary to enhance EDIPOST from being an Australia specific system, to a system which could be configured to work in any country.

IDP have since sold the enhanced EDIPOST system (now named ePOST/Open) to a number of countries.

While working for IDP in Denmark, I installed and configured Linux on a PC for them. Giving them their leased line PPP connection to the Internet.

At this time there was a shortcoming in the packet filtering code in the Linux kernel. In my spare time I developed modifications to the kernel which would prevent that particular style of TCP/IP spoofing. Unfortunately, as I was cleaning up my code to post it on the Internet, an official (and better) patch was released which fixed the problem.

After completing my work for International Data Post, I rejoined the EDIPOST project.

My first task involved devising a process in which all of the EDIPOST customers could be migrated from the EDIPOST system to the anticipated ePOST/Open system from International Data Post.

The results of this project was a suite of programs, library utilities and documentation which I wrote to minimise the maintenance task for all EDIPOST customer interface programs.

For a number of reasons, Australia Post decided not to install ePOST/Open, but to instead continue to enhance the EDIPOST software.

After Australia Post decided not to install ePOST/Open, I assumed primary responsibility for maintenance and enhancement of EDIPOST. The bulk of this task involved implementing, documenting and retro-fitting a series of API's to improve the quality and maintainability of the code.

The largest enhancement I added to EDIPOST was the ability to deliver documents via facsimile.

To access this facility, the EDIPOST customer simply flags documents for facsimile delivery. Upon submission to EDIPOST, documents flagged for facsimile delivery are automatically queued for submission to an off-the-shelf facsimile broadcast system (OS-FAX from Osiris Systems).

The EDIPOST operators do not need to know that the fax software is present. The software I wrote monitors and manages OSFAX on their behalf. All events, failure and success, are fed back into the EDIPOST system so that unified reporting and job management can be achieved.

Part of my software wrapper around OSFAX included a GUI written in Perl/Tk. The GUI component communicates to the daemon part of the wrapper via a TCP based protocol. This allows remote, realtime monitoring / controlling of the fax delivery process. In normal operation, the operator does not need to interact with the fax delivery process, it happens automatically. Among other things, the GUI gives the operator the ability to override the automatic operation to stop or resume entire jobs; cancel, retry or force transmission of individual documents.

Another large enhancement was some software to integrate a third party document printing and formatting system called Printsoft. Printsoft runs on Windows 3.1, so some software was required to transparently get the print batches from EDIPOST on the Sun workstation to the Windows PC so that Printsoft could produce a spool file. Once the spool file had been produced by Printsoft, the spool file had to be automatically delivered to our network based printers.

The integration program was written using Microsoft Visual C++ 1.52 (for Win16). I used the Microsoft Foundation Classes (MFC) for the GUI. I developed a group of classes which subclassed the Windows Listbox control to produce a multi-column list with column titles and user adjustable column widths.

The program manages print queues for multiple network based printers, and can accept print batches from multiple hosts on the network. All of the TCP protocols were developed directly in WINSOCK 1.1.

I developed a unix hosted utility in C that could deliver spool files to the two types of network based printers that are used in EDIPOST. The QMS printer uses FTP to accept spool files. The Delphax printer uses a proprietary protocol. Both TCP protocols were implemented in this program.

When EDIPOST changed Internet Service Providers, I installed and configured Debian Linux on a PC to provide the project with a firewalled PPP connection to the Internet.

Top of Résumé