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 <[EMAIL PROTECTED]> Reply-To: Horst Herb <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 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 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
