Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 32074 invoked from network); 16 Mar 2009 19:48:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Mar 2009 19:48:00 -0000 Received: (qmail 78316 invoked by uid 500); 16 Mar 2009 19:48:00 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 78105 invoked by uid 500); 16 Mar 2009 19:48:00 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 78096 invoked by uid 99); 16 Mar 2009 19:48:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Mar 2009 12:48:00 -0700 X-ASF-Spam-Status: No, hits=3.4 required=10.0 tests=FS_REPLICA,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 74.125.44.30 as permitted sender) Received: from [74.125.44.30] (HELO yx-out-2324.google.com) (74.125.44.30) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Mar 2009 19:47:53 +0000 Received: by yx-out-2324.google.com with SMTP id 8so831091yxm.55 for ; Mon, 16 Mar 2009 12:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=vd/9iPhgq2BDjDvfsCTYOwvG1bBhsjZE3FAZiJQY4Fc=; b=n7aUHA2itjphv9aaJvFkHyZ1+ei8SQtxJJQRU5S9bjxACHLRIPgXZidmwcBEF1bsb+ xrkK5VWQNnsSPMBYQD7hbYI1qfJEIZf9cehjRhcl4jVnoDcM7iPnGust9g6Ibvt2bdrr ngS7jpcu/3JAhimgKgvbIg7px3yUIWY7D+io0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NWtYTS/dDhm22reIu0Kt6W5r1GcxD17G2rHqzDQXiIRZXJipLYDXMoYGGjn+SzjJUz N1JP9yHtfK+pI5ZNXtZaVPH0IEnLZ5+LNXvmYTUjqDCG9/WJtd0euzQ2nZjUMFde5QHY yMyq9JRRLEwSuiApV4HPqrX7QdgkazwlBIgiU= MIME-Version: 1.0 Received: by 10.231.10.194 with SMTP id q2mr1081367ibq.0.1237232852390; Mon, 16 Mar 2009 12:47:32 -0700 (PDT) In-Reply-To: <49BEAB8A.6070000@nextury.com> References: <49BA6F13.5060709@nextury.com> <49BDD795.6010206@gmail.com> <49BE351E.3000805@nextury.com> <49BE79FD.3070202@nextury.com> <49BEA412.1000307@nextury.com> <49BEAB8A.6070000@nextury.com> Date: Mon, 16 Mar 2009 15:47:32 -0400 Message-ID: Subject: Re: Replication configuration : second thought From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=00032557454aabd47c046541b873 X-Virus-Checked: Checked by ClamAV on apache.org --00032557454aabd47c046541b873 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Mar 16, 2009 at 3:42 PM, Emmanuel Lecharny 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. Alex --00032557454aabd47c046541b873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 16, 2009 at 3:42 PM, Emmanue= l Lecharny <el= echarny@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.
=A0 =A0


Yes this is what the core DirectoryService should be. =A0If replication is<= br> needed then LdapService needs to be used.
=A0
Ok, let's start from here then. Assuming that the core is free of netwo= rk is a good base.


=A0
- embedded server with a consumer
- embedded server which is also a producer

=A0 =A0

By embedded you don't mean just the core? Let's be exacting with th= is term.
=A0
I mean, the core. Not the network part.

The following embedded configurations of ApacheDS are possible:

=A0 (1) Only the core without any network services enabled.
=A0 =A0 (2) The core and the LDAP server together with potentially other n= etwork
services enabled.
=A0
Right. This is from this starting point I'm trying to figure out the be= st possible place to put the replication layer.


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

Now that we're using syncrepl which sits on top of the LDAP line protoc= ol,
it makes sense to have it enabled with the frontend in the 2nd configuratio= n
I wrote above.
=A0
Ok. There is one little things remaining then (see later).

=A0
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 wh= en
just a client would be enough ?

=A0 =A0

Consumer or actual LDAP client don't understand.
=A0
Consumer. Sorry for the confusion.


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

=A0 =A0

These are bad choices IMHO. It's yet another new way things can be setu= p. =A0I
think you should keep the LDAP protocol stack and replication together as part of the frontend since it is inherently part of the frontend.
=A0
Hmmm, you may be right.

Just remember we cannot please everyone. =A0There will be people who want j= ust
the core but then find they will want replication too. =A0Those folks can j= ust
enable the frontend and get replication. =A0I don't see any other way.<= br> =A0
The only thing we can do is to allow a use who want to embed the server _an= d_ 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. S= hould be easy.

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

Alex
=A0

--00032557454aabd47c046541b873--