Re: should one single search be able to encompass several databases?

[Alex Martin <a.j.martin@qmw.ac.uk>]

I wasn't going to generally announce this for a week or so when the next
release is ready...but since its relevant to the discussion.  The 
"Info provider" modules are basically rewritten back-ends, instances of
which may be "mounted" at arbitary points in the DIT.  For my purposes 
I'm mainly interested in cacheing the info...but this need not be the case. 

Anyway the current release is available as an RPM at:

http://www.gridpp.ac.uk/download/development/RPMS/openldap-ftree-2.0.11ft0.7.2-1.i386.rpm     

with the source in the SRPMS directory.  

cheers,
Alex



---------------------------------------------------------------------------------------------------


                             back-ftree slapd module
                             =======================
			      

The back-ftree backend slapd module is designed to be a flexible 
memory-based directory-like tree structure. The tree structure is initiated
when the slapd server is started by reading a flat-file in ldif format. The
objects so read are stored internally in openldap's internal format and the 
application  of filters etc use the build-in matching functions. Because 
it is memory based, access speed is maximised. 

By default the LDAP entries are constructed directly from the ldif entries. 
However, its also possible to define ldif entries which  correspond to
actually correspond to "information providers". In this case the 
"stub" ldif entry actually provides the configuration information 
for the provider. For example, the ldif entry:   
  
dn: hn=localhost, dc=gridpp, o=grid
objectclass: shellstub
dynamictype: shell
shelltype: simple
script: /opt/ftree-demos/loads.pl
suffix: hn=localhost, dc=localdomain, o=grid
frequency: 10

Tells the server that the entries, rooted at "hn=localhost, dc=gridpp, o=grid"  are to be 
provided by an info provider of type "shell"  which runs the shell /opt/ftree-demos/loads.pl. 
Updates are requested every 10 sec.

The info providers are implemented as additional dynamically loaded modules 
which may be loaded into the server (currently at start time), and may contain their 
own threads of execution. 

Four info provider modules are currently provided:


back_ftree_shell     which  provides support for legacy shell scripts compatible with 
                     the standard back_shell module, also "simple" shell scripts which
		     simple produce a ldif listing on their stdout  

back_ftree_cache     which allows one to cache the entries provided by another server.

back_ftree_logfile   which builds a LDAP structure from the contents of a logfile 

back_ftree_perl      which preloads a perl interpreter, so calls to perl modules are 
                     intrinsically fast. (think mod_perl).  





-------------------------------------------------------------------------------
|                                                                             |
|  Dr. Alex Martin                                                            | 
|                                         Physics Department,                 |
|  e-Mail:   a.j.martin@qmw.ac.uk         Queen Mary, University of London,   |
|  Phone :   +44-(0)20-7882-5033          Mile End Road,                      |
|  Fax   :   +44-(0)20-8981-9465          London, UK   E1 4NS                 |
|                                                                             |
-------------------------------------------------------------------------------