On 3/17/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
Hi, Directory developers,

I have SASL updated and working great with the results of our
discussions from this week.  I have to say, I'm pretty psyched to have
this running with a lot tighter configuration, even if it is more of
the same Spring XML.  

That's wonderful.  I'm excited to have SASL with a tighter configuration
than using env properties.

One of my favorite sayings is "The opposite of
incremental is excremental."

Heh I like that too.

I noticed one easy improvement to configuration that I've seen in
other servers using SSL, such as Tomcat and Jetty.  In Jetty, for
example, you have a "Server" with "Listeners," each Listener on its
own port, paraphrased here:


IMO it makes a lot of sense to have separate beans for LDAP and LDAPS.
The underlying class, LdapConfiguration, would be identical but we'd
have 2 beans instead of today's ldapPort and ldapsPort in one bean.

Yeah this sounds pretty sane to me.

With the other 4 protocols, I have a base class called
ServiceConfiguration specifically meant for the parameters common to
all protocol's, such as ipPort, ipAddress, JNDI authentication, etc.
If we went with separate beans for LDAP and LDAPS I could have
LdapConfiguration extend ServiceConfiguration and all the protocols
would be very similarly configured.  For example, every protocol would
have the common parameters ipPort and ipAddress (to bind to in
multi-homed scenarios).  One of the really cool things this sets us up
for is having an LDAP schema for the aforementioned common parameters.
In fact, this is how we do dynamic re-configuration with Config Admin
in the OSGi build.

OK you've got my attention here even though this is more scope creep into
your SASL branch.  However it does not sound like all that much to get done.

BTW it looks like you're close to finishing this off so we might just push this
into 1.5.0.  Also I will make sure I fax in that StartTLS grant today: finding my
fax machine is #1 on my agenda after hitting send here.

More to the immediate needs of SASL, in lieu of more advanced config
someday, this would make it easier to handle what I think is a common
usecase, namely that authentication requirements are different for
LDAP vs. LDAPS.  For example, admins could configure an LDAPS bean to
allow anonymous and/or simple auth connections while the LDAP bean
could require stronger authentication.  Separate beans would allow
separate SASL configuration with very little work.

So, to summarize we would have:

<bean class="MutableServerStartupConfiguration">
  <bean id="ldapConfig" class="LdapConfiguration">
    <property name="ipPort" value="389"/>
    ... SSL config for Start TLS ...
    ... SASL config ...
  <bean id="ldapsConfig" class="LdapConfiguration">
    <property name="ipPort" value="689"/>
    ... SSL config for LDAPS ...
    ... SASL config ...

Having a protocol with 2 ports is a throwing wrench into my protocol
configuration class hierarchy.

Understood.  I can see this problem clearly now.

I could finish this and be stable with SASL this weekend.

Let's go for it.  I agree with all your points in this email.