Re: [Gnumed-devel] gnumed architecture

[Ian Haywood]

On Mon, 26 May 2003 23:38:36 +1000
Horst Herb <address@hidden> wrote:

> Somehow we are moving in circles.
> 
> The original idea was a three tier architecture: user interface, 
> transactional 
> middleware, and dumb datastore
> 
> However, no matter how hard I tried, I found no way of reliably preventing 
> users from bypassing the middleware and doing stupid things on the backend, 
> so we decided to scrap the middleware and implement as much bsiness logic as 
> possible on the server via stored procedures

I'm still attached to this idea, although it does imply a monolithic server
(at least on current versions of PostgreSQL, distribution at the SQL level may
become a possibility in the future)

> Strangely, this middleware layer slowly seemed to creep into the user 
> interface layer via "business objects". Now the UI client gets fatter and 
> fatter. Do we want this?

Certainly not. 
One advantage of XML-RPC (on Python) is that these business objects can be 
either
local or remote (if written properly)
 
> We would not even need the rather heavy PyGresQL+ DateTime libraries on the 
> interface clients any more. We could stop bickering which way to present data 
> on the user interface is best, since user interface implementation would 
> become more trivial again.

Are you advocating multiple GUIs? Perhaps one per developer, at least ;-)
Joking apart, diversity is good here as GUIs will always be a matter of taste.

> If we would limit ourselves to Python (which we should not),

Why? Seriously, are we going to write an entire client or server component in C 
or C++.
Python is small and fast, runs everywhere (hell, it's implemented on Palm Points
[pippy.sourceforge.org])

> Only problem is that I still don't know which RPC interface wil be best 
> suited 
> and most future proof for us. 

So long as it's not SOAP (complex and ridiculously bloated, the Java of RPC) I 
don't mind.

> And I still don't know what the most sensible 
> way of splitting our database into services is. 

I thought we were working around

1. Demographics
2. Drugs
3. Guidelines/decision-support
4. Billing (a bridge to GnuCash is increasingly becoming a possibility here)
5. Scheduling
6. Clinical [I don't think there's any sensible way to split this]
7. Radiol/Path

pgpFhDt34A2tg.pgp
Description: PGP signature