gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: web frontend/patient singleton


From: Ian Haywood
Subject: Re: [Gnumed-devel] Re: web frontend/patient singleton
Date: Sun, 30 Jan 2005 19:11:18 +1100
User-agent: Mozilla Thunderbird 0.8 (X11/20041012)

catmat wrote:

yes ,  gnumed uses the postgres authorization system which is sensible,
although this makes connection pooling more complicated. I haven't thought how to integrate tomcat's connection pooling with the gnumed
You don't: use our pooling, tomcat shouldn't establish it's own connections to 
the DB at all.
agreed, linux handles lots of processes easily and gmPG, gmDispatcher, gmCurrentPatient , everything,
is setup to handle just one patient at a time.
No. Multiple *patients* is easy, just hold several gmPatient objects. You 
shouldn't
need to use gmCurrentPatient at all. However this does mean specifying the 
current patient
in the web page links somehow, instead of the Java struts session (which 
presumably
is held as a cookie, so shared between browser windows/tabs)

Multiple *users* is hard -- gmPG does have the assumption that there is only 
one user.
thereafter ,  the initial connection pooling user can be gm-dbowner,  who then
can do   ' set session authorization to "any-doc"  '  if any-doc is the session 
user in tomcat.
Yes, this can be done (gmPG needs an extra method to do it, but that's easy) 
However it raises
a security issue, as users can get to each others cached business objects, 
unless you're careful.

What Java<->Python RPC mechanism would you use? XML-RPC is obvious, but it 
doesn't natively handle remote objects,
so the Python XML-RPC server would need to hold all the business objects, and 
provide a set of procedures to access them.


Ian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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