directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Replication configuration : second thought
Date Mon, 16 Mar 2009 19:27:52 GMT
On Mon, Mar 16, 2009 at 3:10 PM, Emmanuel Lecharny <>wrote:

>  what about having an embedded server with replication capability ?
>> Embedded does not mean the protocol is not exposed.  You can embed with
>> the
>> front end or without.  Without the frontend you will not get replication
>> either since our replication sits on top of the LDAP protocol now.  So it
>> makes more sense to do this in the frontend IMHO.
> If the front end is LdapService, then  the problem is that you can't start
> it without starting the network part of it... You can't have an embedded
> server which is a replica of another server, but without all the bells and
> whistle of a full server. Sometime we may need just the outgoing part
> without the ingoing...
>>> that's a good question... I would tend to think that injecting the
>>> replication subsystem into the core server is probably a better way, as
>>> it
>>> will be available not only to the standalone server, but also for an
>>> embedded server (all in all, the networked server just embedded the
>>> core...)
>> I would respectfully disagree here.  Those who just want to embed the core
>> without the LDAP protocol and socket servers do so because they do not
>> want
>> to expose anything.  We would still have to expose a network protocol even
>> if not the entire LDAP protocol, to do replication.  It makes less sense
>> to
>> me to put the network machinery into the core.
> We should consider three cases :
> - no replication at all, nor as a consumer neither as a producer. This is
> what you describe.

Yes this is what the core DirectoryService should be.  If replication is
needed then LdapService needs to be used.

> - embedded server with a consumer
> - embedded server which is also a producer

By embedded you don't mean just the core? Let's be exacting with this term.

The following embedded configurations of ApacheDS are possible:

   (1) Only the core without any network services enabled.
   (2) The core and the LDAP server together with potentially other network
services enabled.

Now in the 1st configuration I don't see replication as available.  It
should not be available.  Trustin broke this order by developing mitosis in
a vacuum.  I intend to correct this mistake.

Now that we're using syncrepl which sits on top of the LDAP line protocol,
it makes sense to have it enabled with the frontend in the 2nd configuration
I wrote above.

> In case 3, then better start the LdapService, as it has everything
> In case 2, i don't see why we should also get all the LDAP machinery when
> just a client would be enough ?

Consumer or actual LDAP client don't understand.

> Maybe we need an intermediate machinery, not in the core but not in the
> service ?

These are bad choices IMHO. It's yet another new way things can be setup.  I
think you should keep the LDAP protocol stack and replication together as
part of the frontend since it is inherently part of the frontend.

Just remember we cannot please everyone.  There will be people who want just
the core but then find they will want replication too.  Those folks can just
enable the frontend and get replication.  I don't see any other way.

Frankly I cannot discuss this ad infinitum since life is crazy at the moment
for me. But the call is yours since I'm not involved in this effort. I just
know that you'll tell 6-8 months later that I was right :-).  This however
will increase entropy and require more work to correct and this is what I
don't want for anyone.  It will be a waste.


View raw message