On Mon, Mar 16, 2009 at 3:10 PM, Emmanuel Lecharny <elecharny@apache.org> 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.