On Mon, Mar 16, 2009 at 3:42 PM, Emmanuel Lecharny <firstname.lastname@example.org>
Ok, let's start from here then. Assuming that the core is free of network is a good base.
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.
I mean, the core. Not the network part.
- 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.
Right. This is from this starting point I'm trying to figure out the best possible place to put the replication layer.
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
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.
Ok. There is one little things remaining then (see later).
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.
Consumer. Sorry for the confusion.
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.
Hmmm, you may be right.
Maybe we need an intermediate machinery, not in the core but not in the
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.
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.
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.
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.