gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] LDAP


From: David Guest
Subject: Re: [Gnumed-devel] LDAP
Date: 17 Aug 2002 10:34:19 +1000

On Sat, 2002-08-17 at 00:48, Tony Lembke wrote:
> 
> On Friday, August 16, 2002, at 08:46 AM, richard terry wrote:
> 
> > Tony, how about a quick explanation of what LDAP/Server is, how it 
> > functions
> > etc, displays info etc.
> 
> Terry,
Richard might be interested too. ;-)


> I'm not an expert on LDAP but this is my understanding. I'm sure others 
> on the list are more familiar with it then I.
Not me but I've never let ignorance stop me from posting. 

snip

> The database in a LDAP server is a 'flat' , hierarchial database, as 
> opposed to a relational database. All information about an entry is in 
> the one record.
> 
> You therefore do not 'normalise' everything, which wouldn't appeal to 
> Horst's sense of order and would probably make it inappropriate for 
> storing all the demographic data. LDAP servers often have a full 
> database as the backend (like postgresql).

I gather that the Berkeley sleepycat db such as Tony uses for the pksd
keyserver (keyserver.medicine.net.au) is blindingly fast at serving up
data from huge datastores. 


> The way I see it fitting in to gnumed is that when, say, writing a 
> letter to a physician, when you enter their name, if the 
> address/email/phone number are not available on your system, gnumed 
> would query the ldap server for the information.
> If your division used the ldap server for its resource directory, it 
> would seamlessly always be up to date for you, too. Each practice would 
> not have to store the same information.
> If all the divisions in NSW used a LDAP server, the information that is 
> common to the state sphere would be shared between them and their member 
> GPs.
I believe one LDAP server on the backbone could technically handle all
forseeable requests from all Australian doctors. Politically however a
series of (probably) divisional based LDAP servers would be more
acceptable and the data in them more easily maintained by Divisional IT
and administrative officers. 

I think any non-LAN based LDAP server would require better than modem
connections. Synchronising a surgery ldap server with the Divisional one
would be seamless one configured properly, however.


> I'll fiddle around with the server and some schemas and post them to the 
> list for consideration.
I look forward to it. 

> Regards,
> 
> Tony Lembke
> 
> Further reading
> ----------------------
> Introduction to LDAP
>             <http://www.ldapman.org/articles/index.html>
> LDAP in action
>              
> <http://www.linuxworld.com/linuxworld/lw-1999-07/lw-07-ldap_1.html>
> Lighting up LDAP
>             
> <http://www.linuxworld.com/linuxworld/lw-1999-07/lw-07-ldap-
> tutorial.html>
> An overview of LDAP-based directory service from the University of 
> Michigan
>             
> <http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/1.html#RTFToC1 >
> openLDAP server
>             <http://www.openldap.org>
> web2ldap

-- 
David Guest
GPG key ID BE79B742 @ pgp.mit.edu
Fingerprint: 2609 DB95 C040 5902 BA0C  4D3C F1F2 EA62 BE79 B742

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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