directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: [SASL] SASL configuration
Date Thu, 15 Mar 2007 20:28:29 GMT
On 3/15/07, Alex Karasulu <> wrote:
> On 3/12/07, Enrique Rodriguez <> 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

> 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?

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

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.


View raw message