Re: [Gnumed-devel] re: sourceforge ldap

[Karsten Hilbert]

> > is around the corner. It'll make it impossible/very hard to
> > install GnuMed at a few sites I was thinking of because they
> > simply neither have a permanent internet link nor a spare
> > UNIX-Server hidden away somewhere. Or else make GnuMed depend
> > on LDAP when and only when the contacts widget is actually
> > loaded. 
> My intention was it would only depend on LDAP when the *referrals* widget
> was loaded. 
> However I am happy to work on support for contacts in SQL too if the 
> referrals module will be used at these non-LDAP sites
> (will it?)
Sounds fairly OK to me. None of the immediate deployments I
am thinking of touch anything near a referral. Evenutally
they will but in all fairness I can't derive a good argument
from that *today* :^)

> In this case, we need a way *in the GUI* for accessing demographics data 
> without opening a patient.
You are correct there.

> (this was my point before, I wasn't being clear: it's true at the business 
> layer the two services are fully independent)
> Another module, separate client program, or what? Personally I don't mind so 
> long as the decision is clear.
IMO that depends on the amount of functionality. Implementing
a "full-blown" contacts manager should be separate from the
standard GnuMed client (since it doesn't need the concept of
"active patient") -- and it would agreeably be silly, too, as
Horst will surely point out :-) since there is any number of
such out there already and it is of course much more elegant
to leverage them. OTOH a simple contacts "picker" with some
limited few edit functions (like spell-correct the name of a
doc or change the address) would be OK in a GnuMed standard
client notebook plugin. That neither has to care nor work
with the active patient. It simply instantiates gmPerson
objects as needed (IF needed).

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