gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Do have the green light? (was: so, where are we now o


From: Horst Herb
Subject: Re: [Gnumed-devel] Do have the green light? (was: so, where are we now on data persistence)
Date: Thu, 29 May 2003 20:24:31 +1000
User-agent: KMail/1.5

On Thu, 29 May 2003 18:12, Ian Haywood wrote:

> This is looking good.
> Could we be nearing the stage were we can begin offically connecting the
> GUI? [In reality, Karsten has already started of course]

Oh, it had started longer ago - the version I presented in London already did 
it, and my "appoinment scheduler" (similar in testing subdir) was in trial in 
my surgery for two weeks. Yes, we should go ahead.

> Obviously, the selection of the GUI<->business object interface is the
> biggie.

Yes. And agreeing on a single plugin / window manager architecture, IMHO.

> I want to lobby for PYRO, on the following bases:
>
>       - there are no foreseeable plans to write *whole components* in a 
> language
> other than Python [of course we may need to use other languages at some
> level: C for manipulating radiographs, and it looks like we need Java to
> talk to HIC servers] Python runs on any concievable platform, and can link
> to the above two languages easily.

We should not see gnumed in isolation. The breakdown into services has as 
primary objective component interchangeability. Why not let OSCAR use our 
demographic server, for example? However, if we have Python specific RPC 
protocols, not many other projects will develop an interest I suppose.

>       - thin implementation. [This is an academic point, since any deployment 
> of
> gnumed clients has to lug the six-meg wxWindows DLL around. Even CORBA (the
> heaviest client-side) is just 2 meg]

PYRO is absolutely great, Nirwana for Pythonistas, no doubt. Only concern see 
above. wx is not that much of a bloat: we are using only a small subset of 
it's functionality, and if you weed it out (like with freeze or py2exe) you 
end up with some compressed 2-3 MB package for the whole client including wx, 
psotgres and all gnumed stuff - which is not too bad.

> AFAIK, Both PYRO and XML-RPC server classes can be mixins to existing
> classes. This means plain business objects can be attached to either, so if
> someone absolutely has to use another language (say C# for a Windows-native
> client) they can run GNUMed through XML-RPC.

Yes, certainly. But that would require entirely different strategy: Pyro 
passes real Python *objects* around, with methods and properties and all. Can 
do with XML-RPC of course, since Python can interprete code on the fly - but 
would require a lot of work and again be Python specific.

Have another look at XML-RPC via Jabber. If the majority wants Pyro though, I 
am all with you.

I am all itching to produce some code, but we had a tragic event in the family 
(my wifes younger brother suicided), so she went to Germany with our younger 
two kids to the funeral and sort family matters out, while I am here in Oz 
having to take care of the other two children after long double-booked days 
in my surgery and being on call 3-5 days a week. Leaves very little time for 
anything else.

Horst




reply via email to

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