Re: [Gnumed-devel] Opening the debate re moving to 2.6 again

[Karsten Hilbert]

On Thu, Sep 08, 2005 at 10:21:14PM +0000, Horst Herb wrote:

We've been spending the better part of the last 4 years to
do the following so welcome back to Ground Zero:

> So I started to rewrite the system, this time I wanted to do it properly, and 
> using a non-proprietary backend schema.
...
> I want to clean that up and document it properly before I bother people with 
> it.

> In principle, the architecture looks like that:
> 
> a) every database concept (like "a patient", "a doctor", "an address" etc.) 
> is 
> wrapped into a gmdbXXX class with standardized high level accessor methods. 
> They all inherit common traits from a gmdbObject ancestor including a very 
> simple and crude caching mechanism.  There should be no SQL queries at all in 
> the GUI code
Hm, this sounds suspiciously like gnumed/client/business/*.py

I have to admit I haven't yet been able to see through the
caching mechanism. I am sure keen on learning whether it
provides benefits over what we use in GNUmed.

> b) every possibly self-contained functionality (e.g. "prescribing", 
> "appointment booking") exists as an independent module which can be run 
> either standalone or as a plugin within the gnumed framework
While nice and having been tried I have found it to be hard
to maintain. Likely our GNUmed code isn't clean enough yet.
Once you get to a certain complexity of functionality there
are assumptions in the code that are met by the framework
which isn't available when running standalone ...

> c) all such independent modules ( regardless whether gui or not) communicate 
> with each other exclusively via the central messaging hub (dispatcher)
Likely we have taken a few corners here that prevent us from
running plugins standalone.

> d) as a rule, GUI components are designed with wxGlade. The generated GUI 
> code 
> is never modified manually, but a wxXXX module inherits from the generated 
> wxglXXX module.
How does this allow for creating widgets from non-wx-Core
GUI classes ? Say I wrote a dedicated progress note
notebook, how can I use it in wxGlade ?

> f) Not only for simplicity, but also for speed reason, the backend schema is 
> not always normalized.
Does it properly support clinical encounters and episodes
of care ?

> At times, where it would yield a substantial 
> performance gain, foreign keys *may* be the data itself
"would" or "does" as in "tested" ? I doubt it'll make much of
a difference in most cases. Or so the PostgreSQL people
attest to.

> g) the backend schema is versioned. Modules check what backend version they 
> need. The backend is updatable incrementally - after the first full version 
> number, only "update" schema sql snippets will be generated, allowing update 
> of a running system without anybody having to log out first
Same as GNUmed.

> h) installation should be running "gnumed.sh" and "python setup.py install" 
> and nothing else, no hoops to jump through for the end user. This requires an 
> administrator running gnumed.sh as somebody who has the right of creating new 
> postgres databases and users
Yup, that is doable with GNUmed as it exists now. Do you
intend to store program bitmaps (icons) in the database
generated from python encoded inline data ? Or else how do
you intend to make "python setup.py install" install bitmaps,
docs etc in a client system ?

Trust me, been there, done that.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346