|
From: | Jim Busser |
Subject: | Re: [Gnumed-devel] Gnumed-client ... ability to call another gnumed as slave |
Date: | Thu, 16 Jul 2009 08:35:26 -0700 |
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 recordb) without the ability to search another patientWell, 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 ??
[Prev in Thread] | Current Thread | [Next in Thread] |