[Top][All Lists]

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

Re: [Gnumed-devel] Re: low performance

From: Ian Haywood
Subject: Re: [Gnumed-devel] Re: low performance
Date: Mon, 7 Jun 2004 18:37:40 +1000

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 
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
>  - 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 
before it becomes usable in any real way, which is why issues of slowness and 
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 
        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) 


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

reply via email to

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