[Top][All Lists]

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

Re: [Gnumed-devel] remote control GNUmed

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] remote control GNUmed
Date: Mon, 28 Nov 2005 17:16:38 +0100
User-agent: Mutt/1.5.9i

On Sun, Nov 27, 2005 at 10:10:40PM -0800, Jim Busser wrote:

> When called as "slave", GNUmed must expect/require login credentials 
> based on whichever user of the legacy app is "calling" right?
No. The local, real life, human user has to activate/start
the enslaved GNUmed instance with proper credentials. It is
then assumed that other processes running on the same
machine are trusted by definition. Not very good, I agree.
The listening GNUmed instance only answers on UNIX Domain
sockets, remote connections are not heard or answered.

> GNUmed, even by remote-control, there is value being able to 
> attribute (record) those changes as having been made by the 
> responsible individual. And so if the legacy app cannot pass this 
> information as part of the "call" to GNUmed, then the user would need 
> to enter their GNUmed credentials before their "call" would be 
> answered?
It is fairly easy to require proper database credentials
from controlling users. What isn't easy is to switch a
running instance to another "owning user". That would have
to be investigated.

> And once that "call" were completed, what would happen to that 
> instance of GNUmed? Would it timeout after inactivity based on 
> whatever configuration is in GNUmed but provided there is sufficient 
> periodic activity it would persist *but* remain responsive only to 
> that user's processes via legacy app?
ATM it remains responsive indefinitly. It, however, requires
proper flow of action, eg unlocking from a patient before
locking into another one, detaching again before
re-attaching, that sort of stuff.

> Would it be important that the legacy app's hooks --- upon logout or 
> inactivity timeout user who called GNUmed --- kill the called GNUmed 
> instance?
No. But they should unlock/detach. A auto-unlock/detach
timeout inside GNUmed might actually be useful but can
easily be added if the need arises.

> And suppose any particular user, whose activity in the legacy app had 
> called GNUmed as slave, wanted to browse GNUmed to further examine a 
> patient' s information (or to input directly into modules that make 
> no sense to run from inside the legacy app) --- would the user just 
> bring the already-running instance of GNUmed into the foreground? Or 
> does anything about the GNUmed "slave" instance prevent it being used 
> normally, meaning the user would have to launch a second (i.e. 
> non-slave) instance of GNUmed?
Yes and no. The enslaved GNUmed has it's patient
search'n'select disabled. So, as long as the user wants to
stay  with the patient activated by the legacy app things
are intended to work just as in any other instance.

I do suggest having a couple of instances running at any one
time - I routinely use four on the machines at my work.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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