Re: [Gnumed-devel] Re: low performance

[Ian Haywood]

On Mon, 07 Jun 2004 11:07:54 +1000
sjtan <address@hidden> wrote:

> Message: 2 Date: Sat, 5 Jun 2004 19:04:33 -0400 From: Ian Haywood 

> Maybe we should experiment with a backend xml-rpc server now , to see 
> how much a local business object server
> and local sql communication  will speed up remote communications, as 
> Karsten as mentioned.
To be honest I remain sceptical: XML_RPC is going to add a lot of overhead of 
its
own and the server still has to make all these queries, even if they are over a 
local socket.

> > start typing notes etc. while stuff is loading. I'm not sure about the 
> > best way to implement this yet.
> >
> would be nice if we had non-blocking writes and socket select with db-api !
We can emulate this using threads easily (as we already wrap the DB-API with
gmPG.py)
 
>  - change to request /  event notify / receive   style of business 
> object invocation, instead of rpc style, as is currently.
>           - within the business object, there would be a request queue 
> and a consumer / dbapi calling thread that
> services the queue, and places the results in a synchronized dictionary, 
> then issue  events on a event dispatcher
IMHO this is the way to go. (although I apprecipate its very different from 
what we have)
To digress a little, the problem is for Karsten and Sebastian gnumed is 
something that works Right Now,
and will soon be able to do more stuff, integrated with other clinical 
packages, which
is why Karsten is (understandably) relunctant to go and refactor the design.
However in AU this is not the case: gnumed needs to have a lot more 
functionality
before it becomes usable in any real way, which is why issues of slowness and 
GUI
complexity are more real: I fear the way we are going the client will be too 
bloated and messy
to use.

> 3. unsynchronise business object request, response, and gui update using 
> event driven coding style in the client. Use client-side business object 
> proxies to do the waiting and response notification.
I would envision a middleware that's a bit more like PROLOG: a set of rules, 
each with 4 elements
        1 - the event that fires them (either GUI, backend via NOTIFY/LISTEN or 
internal like "new_patient")
        2 - the GUI-specific function which grabs data from the appropriate 
widgets
        3 - the SQL query, run in the background
        4 - the GUI-specific function which unpacks the data and loads it into 
widgets (which MUST be in the foreground thread) 

Ian

-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E