gnumed-devel
[Top][All Lists]
Advanced

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

Fwd: Re: [Gnumed-devel] experiments with gnumed - multiusers vnc, import


From: Syan Tan
Subject: Fwd: Re: [Gnumed-devel] experiments with gnumed - multiusers vnc, importing an au emr
Date: Sat, 01 Apr 2006 19:58:20 +0800






----- Original Message -----
From: Syan Tan
To: address@hidden, Sebastian Hilbert
Sent: Sat Apr 1 19:57
Subject: Fwd: Re: [Gnumed-devel] experiments with gnumed - multiusers vnc, importing an au emr


don't know if it really makes a differnce in gnumed, it made a difference for another app running windows,

the client would wait until all the data was across the network; when the client ran locally under lin4win or

a terminal server setup, it was apparently much faster .

I thought it has been harder lately to get X windows to work across a network : I remember 5 years ago,

you could ssh into another computer, run any X windowing system using program ( i.e. any gui program)

and if you were running in an x window based desktop, the gui would appear on you desktop.

now I have to trawl through various versions of vnc to find one that works with the right screen area, and

manually run a vncserver on the server first, don't know why it isn't automatic like it used to be.

gnumed probably works well without terminal service,

I just timed it : the emr tree seems cached, and once loaded ( it takes about 20-30secs for a very large record)

it can redisplay in 5 seconds ( i know the wxtree data is cleared and rebuilt). the emr journal isn't cached

and takes 50 seconds, whether it is a terminal service or plain old remote sql connection.

the queries just need some optimizing I think,

what about an explicit join view as karsten has said ? I'll play around with

a copy of the emr journal , but have to stop procrastinating and finish the importer for the au stuff.

Ideally, both the gui emr journal and the tree should be updated in a multithreaded nonblocking way,

or maybe it shouldn't - if it is blocking, at least there is some sort of assurance that all the information is infront of you

when the gui becomes responsive again.


On Sat Apr 1 10:43 , Sebastian Hilbert sent:

On Saturday 01 April 2006 10:04, Syan Tan wrote:
> I recently asked some questions about how to speed up record access for an
> existing emr,
> which is fairly slow for large records. The answer seemed to be that thin
> client sessions
> works the best if the network isn't good enough.
While I dont fully understand the history of your project I would like to add
some comment. Thin clients are useful when you have a decent network but
slow terminals (old PCs)
Consider using nx instead of vnc. It will perform way better over slow lines.
It features persistent session. You can actually suspend a session. It
features 'vnc'-like exporting of single applications

There has been an artcile by Kurt Pfeiffle on how to simulate slow networks.
http://www.kdedevelopers.org/node/1878
>
> one can set up multiple thin client sessions between two computers running
> debian or any linux to see how gnumed
> performs; my laptop with 512mb 2.8 ghz pentium 4 was the "server", and it
> did quite well
> using vnc4server running on the debian system on the laptop.
> The idea was to create multiple user accounts e.g. user1, user2, etc..
> then copy the gnumed tree into each of the user directories ( make all
> users part of the "users" group and chgrp -R users gnumed-cvs-directory ).
> also have ssh-server running on the server.
> then from the client machine , ssh into each user account, e.g. ssh
> address@hidden, then run vncpasswd , followed by vncserver. the display
> number and the password for each user has to be remembered.
> then logout, and using vnc4viewer laptop: and enter password.
> this will give you a X desktop for each user's display , and my laptop
> managed 6 sessions without too much difficulty ( vnc4viewer gave an
> adequate desktop size for gnumed). In each desktop, then just go into a
> xterm session and change into the gnumed client directory that has been
> copied to that user's directory and run sh gm-0_2-from-cvs.sh
> it doesn't matter if any-doc is used as the gnumed user each time.
Thanks for the generic instructions When using different distributions and
packages the whole process can be shortened quite a bit.
>
> now if you are in au and use a fairly common emr, you can use gnumed
> to browse the patient demographics and progress notes.
>
cool
> the importers scripts are in client/importers/au/md2/a ,
> use dbf_2_pg first to create a postgresql database from the dbf /dbt files,
> and then use the script in gnumed_import to transfer the patients.dbf , the
> doctors.dbf and
> progress.dbf/ dbt into a gnumed_v2 database,
interesting.

Now I get it. Forget about the first statement. We are talking VNC for Winows
here, right ?
--
Sebastian Hilbert
Leipzig / Germany
[www.openmed.org] -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86 -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice

 




reply via email to

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