Re: [Gnumed-devel] gnumed architecture

[Horst Herb]

On Tue, 27 May 2003 21:50, Karsten Hilbert wrote:
> >> 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.

Thirded ;-)
Seriously, I think we all agree on this

> > 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.

Performance (persistent connections!) + authentication is nicely taken care of 
if we run XML-RPC via Jabber. The Jabber client library is slim, and AFAIk 
tehre are even pure python implementatins (no installation troubles for end 
users)

> >> 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.

But we would if we would use the elegant PYRO (Python Remote Objects) as model 
for distributing services/processes. It would be horrendous work to port it 
to any other language (except for Java)

> > 5. Scheduling
>
> Or more general "administration".

Yes. I would actually join billing & scheduling into a single service, 
"administration" would be a good name for it

> > 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)

I would fancy separating clinical from "external reports", but have some 
redundancy in clinical (embedding relevant reports/results into the narrative 
part of clinical)

Horst