The Spec for the reg and mlist rewrite

Introduction and Origins

reg and mlist are two programs that have served Mount Madonna Center (hereafter 'the center') from 1989 to the present day. Versions of mlist actually came before reg - in 1982!. 'reg' is a short name for 'registration'. 'mlist' is a short name for 'mailing list'. They run on SCO Unix version 5.0.5. They're written in a combination of FoxPro and Perl. SCO Unix is a dead operating system, no longer actively supported. FoxPro (for Unix) is an extension of dBase III+ - the long dead Ashton-Tate database language. reg and mlist utilize very few of the FoxPro extensions because they were originally (in 1989) written in dBase III+.

reg and mlist appear to be very simple. They are plain-looking, text-based, keyboard-driven programs. Beneath the surface, however, they are actually quite complex.

reg and mlist were originally written by Sahadev Jon Bjornstad as part of his volunteer work at the center. He is still present and actively maintaining them.

The correct names are reg and mlist, not REG or MLIST.

The Need for a Rewrite

Obviously, the state of the software/hardware world has made extraordinary advances since 1989. reg and mlist are ancient, old and creaky. It is actually quite a miracle that they still work and can be modified. A rewrite is long long overdue.

Having only one person being able to understand and modify the programs is also clearly a severe liability for the center. The time is now (April 2007) for moving the functionality of reg and mlist into the modern world.

Resources

Anyone considering the complex task of rewriting reg and mlist should first become an expert user of the current software.

Here are the many ways to learn about reg and mlist:

  1. Ask Sahadev.
    831-460-2648
    jon@logicalpoetry.com
  2. Ask the program office staff - especially Jayanti and Brajesh.
    408-847-0406 x6
    jayanti@mountmadonna.org
    brajesh@mountmadonna.org

    Visiting the program office in person and sitting a while and observing is highly recommended.

  3. Log in to the unix machine at Mount Madonna and Try It.
    Use the real thing!
    Contact Sahadev (above) for access to the unix machine. You can freely use reg and mlist with test data so as to not impact the current, real, live data.
  4. Read the user documentation for reg and mlist.
  5. For internal technical details read these documents: reg and mlist.
  6. Read this extensive document for information about web page generation and on-line registration.
  7. Since these programs are largely data-centric the table structures are critical to understand. Reg uses two main tables (reg and prog) but housing, finances, leaders, cancellation policies, regi, etc. etc. bring many complications (33 other tables!). Mlist uses one main table (mlist) with 3 others. The structures of all tables are here: reg and mlist.
  8. Read the FoxPro and Perl source for the programs.
    Again, contact Sahadev (above) for access to the unix machine or for copies of the source.
  9. Read this style guide of FoxPro basic language elements, how Sahadev uses it, and what coding standards he follows.

reg and mlist By the Numbers

To give you a sense of the size of this project and to compare the complexity of mlist versus reg here are some numbers:

mlist

reg

Some of the FoxPro files are no longer used - either they were a temporary fix/test or implemented a feature that is no longer needed.

ReWrite, ReThink, or ReDesign?

Certainly the implementation in a modern language will do things in a very different way than reg and mlist are done in FoxPro. Several things will need to be rethought and redesigned.

For one example, there may be no concept of "Next" and "Back" which are ubiquitous in reg/mlist. "Next" and "Back" are simple to do with the 'skip' command in FoxPro but in an SQL based implementation they may not be practical.

Hopefully the basic functions can be inferred or deduced by exploring the resources above. It has taken a long time to identify what is needed and the reg/mlist implementations have met those needs.

So, the first aim of a rewrite should be to replicate the current functionality. Some things are certainly of a lesser priority but there should be a discussion and an agreement as to what these things are. After the current functionality is in place any extensions can be negotiated.

Why Is It So Difficult To Rewrite A Legacy Program?

A humorous (but true) definition of a 'legacy program' is 'one that works'.
reg and mlist do work. They are quirky and sometimes fragile but they are currently serving the needs of the center. Until the rewritten software can match and then exceed the current functionality it will not be possible to switch from the old to the new. This means that there will be an extended period of development without actual live users using the software. There may be a period of parallel use - using both new and old at the same time - but this would mean double-entry of data and would take extra energy on the part of the users. It is also generally true that developing trust for anything new takes time.

Acknowledging the above, it is clear that it will take an extended commitment to develop a modern rewrite of reg and mlist and actually bring it to completion.

The Good News

Two positive items are worth mentioning:
  1. The original author is still present. This is quite rare for software that is 18+ years old!
  2. A few pieces of the puzzle (web page generation, online registration, phone list, etc.) are written in Perl - a current and modern language. This software is easily and directly ported to any MS Windows system. The only trick will be to interface to these Perl scripts by generating and using text files in a well-defined format.