gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] gnumed architecture


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] gnumed architecture
Date: Tue, 27 May 2003 13:50:15 +0200
User-agent: Mutt/1.3.22.1i

>> 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)
Seconded. We don't do much of that yet but I am in favour of
having important business logic in the database.

> One advantage of XML-RPC (on Python) is that these business objects can be 
> either
> local or remote (if written properly)
Agreed. But again I must whine about the lack of proper
authentication.

>> If we would limit ourselves to Python (which we should not),
The keyword here is /ourselves/ and not /limit/. Nothing wrong
with limiting *ourselves* to Python as long as we don't
prevent someone else from writing a Whitespace frontend.

>> Only problem is that I still don't know which RPC interface wil be best 
>> suited 
>> and most future proof for us. 
[...]
>> And I still don't know what the most sensible 
>> way of splitting our database into services is. 
You will never know. It is unknowable. It is a matter of
decision.

> 1. Demographics
Yes.

> 2. Drugs
Yes.

> 3. Guidelines/decision-support
Or more general "knowledge".

> 4. Billing (a bridge to GnuCash is increasingly becoming a possibility here)
Yes. Also a bridge to FreeMed Billing.

> 5. Scheduling
Or more general "administration".

> 6. Clinical [I don't think there's any sensible way to split this]
Agreed.

> 7. Radiol/Path
So why do you try to split it ? :-)

6 and 7 should be IMHO:

6) clinical (+ processable path)

7) non-processable (image/opaque object, that is) content
   - this pretty much amounts to BLOBs or, more specifically,
     GnuMed/Archive
   - it already works

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]