Scripted wrappers for legacy applications, Part 3

We emphasize wrapping existing applications because it's such good engineering. Suppose, as we did in our previous two columns, that you have a command line application that works correctly -- you just want a GUI with the same functionality. The safest way to achieve that is to keep what you have -- the correct, well-exercised command-line application -- and wrap it with a thin GUI.

Even the smallest change requiring a relinking of a compiled application introduces numerous possibilities for error. That's why we so strongly favor a pipe for IPC -- it fits architectures that reuse what you already have.

However, many other forms of IPC can serve in this role. The most important in the Internet age, of course, is a TCP/IP socket connection. Most scripting languages now support networking quite well. One architecture we often use when scripting existing code is C embedded in a computational server and connected to it with simple, networked GUIs. You may remember that the July installment of Regular Expressions mentioned Effective Tcl/Tk Programming as a good read for scripters, even those who don't use Tcl or Tk. In Chapter 7 of that book, authors Michael McLennan and Mark Harrison work out a nice example of this computational service architecture.

What the authors leave unsaid, though, is that their methods are more or less language-independent. Code a computational server in C or Fortran, with a simple protocol for talking to clients. You can then quickly develop client-side GUIs in any language you choose: Perl/Tk, Tkinter, or something more exotic. The point is not to proliferate technologies, but to realize you're free to combine the ones that best suit different requirements of your projects. Use Fortran and PyQt when both are advantageous; teach the two to communicate and you can enjoy the best of two different worlds.

Extending a scripting processor

Think about:

     print("Hello, world.\n"); 

That is a Perl script. Suppose you've coded a little C function that logs results to a central database. You want to take advantage of the work you've already done, and somehow have the capability to write:

     my_log("Hello, world.\n"); 

in Perl, and have it do what you intend. You want to extend Perl.

Extension is more specialized than the process management we explained earlier. The first two installments of this series demonstrated tiny working programs that illustrated important functionality available in essentially all modern scripting languages.

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine