15 July 2010

Simplifying things by complicating them

I have an application to modify which wants to go from a hard-wired Wyse VT-100B-clone character terminal emulation to a GUI interface with all stops in between, plus wants to go from spitting escape-sequences at a specific model of dot-matrix impact printer to spitting A4 pages out of name-your-printer, plus wants to go from unindexed flat (fixed-with binary records) data storage to an SQL backend (probably PostgreSQL to start with).

How do I do this, step by step, so I can continue to validate the functionality of the application at each step?

Feature Set One: wrap all of the terminal I/O in a standard set of functions; then figure out how many pixels wide/high a bog-standard Courier (fixed-width) character is at a standard scale (12 point?), multiply the text coordinates by those factors in the top-level code, then (when addressing a text screen) divide the resulting coordinates by the same factors before cramming the result down ncurses’ throat.

Feature Set Two: wrap all of the printer I/O in another standard set of functions which open a text file, write the print output to that (maybe with embellishments such as bolding), then hand the result to a HTML-to-PDF application (like htmldoc) which then spools the output to a printer or publishes it where an EMail application can attach it.

Feature Set Three: wrap all of the data storage or access code in a set of simple functions which expect & return a fixed-sized memory structure regardless of the underlying storage format. Amongst other things, copying a flock of flat data files into an SQL server’s collection of TABLEs would be a short iterative loop.

No comments: