Implementation Details, Part 2

Although the database server and the transaction server will probably be limited to run on UNIX based environments in the foreseeable future, there is no such restriction for the clients. All the client needs to do, is to provide an easy to use user interface, preferrably a graphical one, to isolate the user from the difficulties of communicating directly with the SQL server. Both server sysstems will takle complete care of the data integrity, therefore it will be possible to run the clients even on unstable operating systems like Microsoft Windows without the constant fear of loosing data.

There are no limits to the design of clients, as long as the client system can communicate via TCP/IP with the transaction server. A client might be a PHP web browser script, a console based application, a fully blown GUI client – it is entirely up to the end user to decide which form of client(s) suits his needs. It is easy to write a small text based client less than 20 kB in size running on a DOS box, and yet providing the end user with most of the functionality of the GNUMed system – although most end users will certainly prefer a modern GUI based application with the look & feel they are used to.

Another possibility is to provide services through a third server, the application server: a fast machine with lots of RAM running the applications for thin X-clients (works fine for me with old 68040 Macs and 386′ with the free MicroImages X server (which is unfortunately not open source)).

We strongly encourage modular design of clients, following the general UNIX philosophy of small tools doing ONE job really good. It is good practice to develop such small applications which easily can communicate with each other (but, as opposed to DLLs and similar libraries) can run on their own still doing something useful).

The more monolithic software gets, the more difficult it is to maintain it error free and to continue the development. The basic GNUMed client will only do some demographics. Script writing, progress notes, pathology, etc – they all can and should be separate applications, each depending as a rule only on the demographics module (although all together will definitely look like one single application to the computer illiterate end user).