[Gnumed-devel] another suggestion

[catmat]

Some years ago, even though I'd picked up a bit of java, I decided to be 
humble ( who me?) , and do a 101 java course.
(Actually, I tried to cheat , and do half the course whilst doing 
another one, and withdraw when I had to pay the course fee,
so maybe my suggestion is incomplete.  I still followed the assignments 
though, and did it in my own time )
The assignment was to write a calendaring application. It was structured 
into 3 stages .  The first stage was to get
a workable application running on the console ( I think with file 
input/ouput as persistence). The second stage
was to add a few features. The last stage was to make a gui application 
with the same functionality; whether
it was adapted from the console wasn't specified, but the lecturer was a 
grumpy  40+ ex-rockclimber / engineer, and
was expecting we'd all f**up with using inheritance / composition / 
re-use  and other oo methods.
Ok so, it was a toy application in its scope, but maybe it had some 
merit in its console functionality acheived / *then* gui frontend 
functionality.

( Actually, I think I ended up using a pipe to communicate input between 
the gui and the console user commands ;
can't remember how I did output though; maybe it was observer with a 
console observer and then a gui observer.
Observers have a handle to the root of the model, and get notified by 
the model when the model changes; observers
then update their particular brand of ui  ). 
gnumed has an observer system , I think (gmDispatcher) , but noone's 
made a simplified console interface first, or yet.

On the other hand , it could be argued that  gui interface apps and 
console apps shouldn't be made the same, as the
first is event driven and the later blocks on input / output streams. 
This was apparently so in a sockets course I did,
but it was based on old Windows C  explicit  event loops, which 
funnelled every event  through a big switch statement, but
maybe it isn't so different from the console  open-socket centred main 
loops.


Another issue is schema versioning ;  gnumed keeps changing the model 
based on some rational refinement that extends over many
months, without much recourse to experimental knowledge gained from 
hooking a working application on it.
I just started looking at a messaging application in java for clinical 
applications, and they've got an interesting versioning system :
they have sql scripts of the a particular starting version which is 
meant to be installed first onto the database system.
Then they have a component that inspects the tables and possible table 
fields and come up with a version number.
then they loop through a list of  versioning objects that have    
methods to drop different parts of the schema in a particular order,
e.g.  indexes, constraints, views, tables, and then  methods to add new 
version  tables, constraints, views , indexes  ; and apply
the versioning objects that have a number greater than the guessed 
current version number , onto the backend schema.

Off topic, another interesting hack they have is to constrain  object 
call paths by throwing  deliberate exceptions and inspecting
the call stack for particular  text   method names,  e.g. just to check 
an object was created through a factory objects method.