Re: [Gnumed-devel] Gnumed-client ... ability to call another gnumed as slave

[Jim Busser]

On 15-Jul-09, at 3:33 AM, Karsten Hilbert wrote:

> On Tue, Jul 14, 2009 at 05:58:10PM -0700, Jim Busser wrote:
>
> > Hi... is it possible for an instance of gnumed-client to drive (and
> > instantiate, if not yet running) an instance of gnumed as "slave"?
>
> Yes.
>
> > However, it is not clear to me what if any is the "application" or
> > "process" (is it the calling instance of the terminal) that is
> > "remote-controlling" this slave?
>
> Nothing is controlling that slave yet.

Is the slave basically "waiting and ready" to be controlled,  
listening on default port 9999, and hopefully only accepting  
instructions from localhost?


> > I was wondering...
> >
> > 1) is there a way for a "normal" mode gnumed-client to be able to be
> > instantiated and, itself, instantiate an additional instance of the
> > client in slave mode?
>
> Yes but not as trivially as it sounds.


Not sure this computes. If a "dumb" practice manager could control  
gnumed-slave through an intermediary script file, could gnumed-client  
not do the same? Wouldn't it just be a matter of providing the means  
for GNUmed-client to "call" an instance of the slave by use of a menu  
command (GNUmed > Launch slave) which would invoke the shell script  
with parameter? Wait a minute... I get it... in the case of the dumb  
practice manager, it is also offering *context* to what is to be  
done, for example it is offering a patient export file whose  
specification is passed as a parameter to the slave which can then  
figure out which patient to import, update or navigate. The client  
does not yet (presently) contain code developed to pass instructions  
to a slave. Is this a correct analysis?

Even as just proof of concept, it might be great of GNUmed, upon  
launching an instance of the slave with a new menu item, would only  
communicate, to the slave, the current patient. Nothing more. This  
would allow anybody attending a demonstration to witness what can be  
done, since GNUmed should have normally (when launched as normal  
client) opened up with *no* patient in focus whereas through the  
above method it would open with the patient of interest in focus.

If there is a wish to under-promise, the menu could be called

        Launch slave (demo)

or      Demo slave

??

> > Patient can now view their record
>
> > b) without the ability to search another patient
>
> Well, they could use another controller to control the
> controlled instance.

You mean... if they had the means to install / operate / access a  
controller on the praxis machine? The easiest way would be to launch  
another instance of the client if the client made such remote control  
easy however the hacker would need credentials.

The guest (desktop system) account could have its access to Terminal  
disabled. But maybe the easiest would be to allow slave to be  
decoupled -- i.e. to stop listening to, and obeying -- remote program  
commands:

        GNUmed > Refuse control

??