[Gnumed-devel] [Fwd: Re: [GPCG_TALK] Drool for XUL]

[Tim Churches]

Is what Horst says (below) of HORSTmed also true of GNUmed, regarding
asynchronous fetching of data?

Tim C

-------- Original Message --------
Subject: Re: [GPCG_TALK] Drool for XUL
Date: Mon, 28 Mar 2005 18:30:48 -0500
From: Horst Herb <address@hidden>
Reply-To: Horst Herb <address@hidden>
To: address@hidden
References: <address@hidden>
<address@hidden>
<address@hidden>

On Thu, 24 Mar 2005 18:39, David Guest wrote:
> One of Horst's plans in gnumed was on slow links to suck demographics
> out of the server and populate the "top" page. Then while you were
> thinking about what you were going to do next, the rest of the record
> was progressively populated in the background. I suppose a web
> interface would use XML for that.
>
> I don't know if this idea is still being worked o

The internal architecture of "mini-gnumed" does it automagically. The
internal
messaging architecture is asynchronous, running in a separate thread.

All gnumed elements are independent modules (like a patient selector
list, an
allergy display / editing widget etc.), communicating asynchronously with
each other.

If for example you select a new patient, a message is broadcasted to all
gnumed modules that a new patient has been selected. All these modules then
queue a request for updated content with a caching module, and simply
display
a default "blank" content until they receive the updated content from the
backend via the caching module (no information has to be fetched twice from
the backend as long as the client has enough memory for caching)

That way, the user interface always remains responsive and appears to
respond
immediately without delay, while all we do is lazily filling content as a
background process where it can't be seen on the current screen

Horst