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

[Ian Haywood]

On Thu, 29 May 2003 08:40:20 +1000
Horst Herb <address@hidden> wrote:

> On Thu, 29 May 2003 08:01, Karsten Hilbert wrote:
> > 3) the widget level dict persists itself to a temp file for
> >    crash recovery, this is to be done generically, preferably
> >    in the background somehow, say, in a thread; upon widget
[--snip--]
> The "on_save" function should be implemented "per panel", not "per widget", 
> with widgets registering themselves with their parent's on_save handler.

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]

What are the remaining obstacles?

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

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.

        - server discovery: now end-users just need their name and password, 
PYRO can find the server
wherever it is on the network

        - the ease of XML-RPC without the XML bloat.

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

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.

Ian

pgpQV2N8zn0eE.pgp
Description: PGP signature