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

[Karsten Hilbert]

On Thu, Jul 16, 2009 at 08:35:26AM -0700, Jim Busser wrote:

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

That's right.

> and hopefully only accepting instructions from localhost?

Yes.

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

Oh, OK, yeah, that would work, of course :-)

I wasn't thinking the extra intermediary.

> 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

Of the slave controller, not the slave. The helper program
"dumb" PMS' can use is a slave controller - it can then / is
intended to be able to start its own slave if necessary.

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

It is but doesn't pertain to the non-triviality I implied.
We do have the code - inside gm_ctl_client.py - so could
just reuse that. That part is fairly trivial. But -- which
slave personality would you want to connect to ? That'd have
to be decided somewhere. That is easy to solve - it just
needs a decision - but the actual content of the decision
can have implications reaching farther than immediately
obvious.

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

Just a nitpick - it'd open w/o a patient in focus just as
well but would then auto-navigate to a patient.

> If there is a wish to under-promise, the menu could be called
>
>       Launch slave (demo)
>
> or    Demo slave

Sure.

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

Yes.

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

Yes.

> 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

"Pause remote control", yes, that could be useful under
some circumstances.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346