gnumed-devel
[Top][All Lists]
Advanced

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

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


From: Dave Cramer
Subject: Re: [Gnumed-devel] GNUmed web interface - technologies
Date: Sun, 11 Jul 2010 17:21:09 -0400

On Sun, Jul 11, 2010 at 12:37 PM, Sebastian Hilbert
<address@hidden> wrote:
> 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 ?

The question was whether or not to use some server side web framework.
Django to be specific.

While I haven't used it specifically, I would imagine it has some form
of ORM in it. This is what I see as being problematic. It would not be
using gmPG2.

>
> 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).

I'm sure it can be done. just not as easily as say using django as the backend.

>
> 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.

Yes, it can be synchronous. google "comet" To be honest synchronicity
should not be an issue within a local area network. IE within a praxis
( I hope I'm using that work properly)

Dave



reply via email to

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