[Top][All Lists]

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

Re: [Gnumed-devel] GNUmed web interface - technologies

From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] GNUmed web interface - technologies
Date: Sun, 11 Jul 2010 18:37:52 +0200
User-agent: KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.5; i686; ; )

Am Sonntag 11 Juli 2010, 17:53:34 schrieb Jim Busser:
> On 2010-07-11, at 5:36 AM, Dave Cramer wrote:
> > If you are indeed serious about keeping both clients web, and thick
> > then I would think that both of them would have to access the data
> > through some middleware in order to maintain data integrity and keep
> > one codebase.
> Sounds like the ability of *both* clients to access the *same* middleware
> would be useful. Is there an alternative?
> It seems to me there are two modes of interacting with patients' records...
> one patient at a time, and multiple patients at a time.
> There are also two modes of using clients... any one praxis (medical
> practice) could resolve to standardize on a single client, or it could
> decide to allow more than one client (web, thick client).
> Supposing a praxis decided it wanted to allow both, would it be possible to
> contextualize the postgres GNUmed databases, with respect to permitting or
> disallowing concurrent record access?
> It seems to me that, provided a user is only allowed to work on one
> patient's (or one user's) records at a time then the danger of two users
> using two different clients that did not know about each other could be
> managed through controls that postgres might offer on the tables and
> records themselves? Sorry if it is either magical thinking, or
> theoretically workable but unsupported... <g>

I am no expert on this. I currently fail to see the problem. How is using two 
GNUmed wxpython instances talking to the database through gmPG2 and friends 
different from one GNUmed wxypython instance and one web instance ?

As far as I am concerned we are *not*  bypassing the GNUmed middlware. We log 
in through the existing middlware and we get and store data through the 
existing middleware ( I hope this can be done).

This might not be the best of breed approach as far as web applications work 
these days but unless it shows major slowness or complicated code choices to 
make I thing there is no problem.

One thing I still not fully comprehend is the asynchronous parts of a web 
interface. But I have been told that AJAX can also be synchronous. I currently 
have not enough knowledge on that part.


reply via email to

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