Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of enriquer9@gmail.com designates
 64.233.184.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=QIiSwrnVX6j/VyoKshRP4R9oMbEFLmww67ozyTzyWDH6l83JxaBeRMrPPHuvfbWlsxC3VHnZzXdGv0V5x/WkHP5MLPk3DF4cqa/WQ/spRblLDJrNuF4aJxG4iyc4HODq3XzFwMIDXMB6jGsDAiMqSHQaTQz7aGndPi7uY81VUJs=
Message-ID: <568753d90703151328y21056adar3a5b94990e61ffa7@mail.gmail.com>
Date: Thu, 15 Mar 2007 13:28:29 -0700
From: "Enrique Rodriguez" <enriquer9@gmail.com>
Reply-To: erodriguez@apache.org
To: "Apache Directory Developers List" <dev@directory.apache.org>
Subject: Re: [SASL] SASL configuration
In-Reply-To: <a32f6b020703151235r495c2ba5rf2a69579eb77bae3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <568753d90703121820n76021567m551e604a1f6031c7@mail.gmail.com>
	 <a32f6b020703151235r495c2ba5rf2a69579eb77bae3@mail.gmail.com>

On 3/15/07, Alex Karasulu <akarasulu@apache.org> wrote:
> On 3/12/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > ...
> > I could also move over the 3 properties that are used by the LDAP PP
> > from the ServerStartupConfiguration:
> >
> > maxSizeLimit
> > maxTimeLimit
> > isAllowAnonymousAccess
>
> There are a couple snags to watch out for.  First you want to make sure
> those configuration parameters are not used by the core context factory.
> Secondly watch out for maven dependency issues ... these have come up on
> occasion.

Right, what I'm proposing will improve dependency issues.  For
starters by inverting the dependency the LDAP protocol provider has on
StartupConfiguration.  Instead, ServerContextFactory depends on
LdapConfiguration.

> Other than that I cannot see many issues.  However what's wrong with keeping
> these configuration properties together with the configuration objects?
> Keeping the configuration in one place may have advantages for us later when
> we clean things up and put all these parameters into the DIT under the
> system partition for DIT based configuration.

Anytime you keep anything together, you are restricting modularity.
Today the assumption is that users of the
ServerContextFactory/ServerStartupConfiguration want to use both the
LDAP and Kerberos protocols.  This may be correct for most people, but
it simply doesn't scale, especially when you consider the addition of
richer configuration for LDAP/SASL and the Kerberos, DNS, DHCP, and
NTP protocols.

As for helping us later, I disagree.  Making configuration more
modular in fact makes a migration to anything new a bit easier.  You
can move one bean at a time to what ever is new.  If not we're looking
at some "big bang" migration.

> Also I we need to think about what users might prefer.  It might be easier
> for embedders to have all the configuration options available in the startup
> configurations either as part of that object or as a contained object like
> the PartitionConfiguration etc.  I think access should still occur from this
> central location so users can drill down into contained objects etc with
> ease.  Or can this be done with what you're suggesting?
>
> WDYT?

I think it is well-established that developers want modularity.  As
for users, keep the configuration more modular means entire beans can
be left out of configuration if they are for a capability that is not
needed.

The central location for drilling-down into a bean will still be a
central startup class, like today's ServerContextFactory.  I would
argue that having the LDAP bean separate is in fact easier to
drilldown into, since it isn't behind another class, namely the
StartupConfiguration or ServerStartupConfiguration class.  These deep
drilldowns violate the law of Demeter, too.

Enrique