[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] gnumed architecture
From: |
Ian Haywood |
Subject: |
Re: [Gnumed-devel] gnumed architecture |
Date: |
Tue, 27 May 2003 21:06:28 +1000 |
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