Should slurpd as a separate process?

[Ganesan R <rganesan-ldap@myrealbox.com>]

Hi,

I am working on storing replication information as subentries following the
LDUP Information model IETF draft (draft-ietf-ldup-infomod-04.txt) as
closely as possible. We need this feature because managing replicas using
config files with multi-master replication is a major pain. 

Some time back, I had modified slapd code so that it can "trap" a replica
addition through LDAP and "reinitialize" it's known replica set. In the last
few days I've made changes to slurpd so that it can detect a "new" replica
and start a replica thread for it. 

I have been thinking about the actual replica addition and deletion process
and facing some issues because slapd and slurpd are separate
processes. Here are examples of some issues I am facing.

1. Consider the no replica case; slurpd will not startup. As soon as the
   first replica is added, slapd has to somehow start the slurpd process. A
   workaround is to have an idle slurpd process around all the time.

2. Multiple OpenLDAP instances on a single box; since the replica
   information is now in LDAP and not a conf file, slurpd needs to know the
   slapd port. Workaround is to add a "slapdport" in the conf file or a
   command line option to slurpd.

3. Initializing a new replica; i.e pushing the current directory information
   tree (DIT) needs to be pushed to the new replica (currently done via
   slapcat + slapadd or equivalent) is easier if driven from slapd instead
   of slurpd reading it through LDAP first and then pushing it out again. 

There are other cases that I can't remember right now. Any way, all these
issues leads me to wonder if we can just merge the two processes. slapd is
multi-threaded anyway, so there seems to be little logic maintaining a
separate process for a core functionality like replication.

Ganesan