On Mon, Mar 16, 2009 at 3:42 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:

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.
Ok, let's start from here then. Assuming that the core is free of network is a good base.

- 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.
I mean, the core. Not the network part.

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.
Right. This is from this starting point I'm trying to figure out the best possible place to put the replication layer.

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.
I agree.

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.
Ok. There is one little things remaining then (see later).

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.
Consumer. Sorry for the confusion.

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.
Hmmm, you may be right.

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.
The only thing we can do is to allow a use who want to embed the server _and_ benefit from the replication as a consumer (not a producer). That means we must allow users to disable the incoming LDAP part in the LdapService. Should be easy.

Yeah.  But we need not do this now.  Let's just get this working and organized properly wrt to the configuration.  Anyways users can use ACI and other techniques to constrain what can be done through the LDAP service if they want replication but do not want to expose LDAP.  This is definitely icing on the configuration cake.