directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject [ApacheDS] Architectural Progression (Was: Re: [SASL] SASL configuration, part 2)
Date Fri, 16 Mar 2007 01:00:02 GMT
Enrique,

Thanks ... there will be a day don't worry for cleaning up all this.  The
mindset
now is to add as many critical features as possible without shifting the
architecture
to accommodate each feature.  Each new feature we add pushes the
architecture
to it's limits and shows us where things fall short.  Things will get a bit
messy but
we're almost there.  Replication and SASL are pretty much the big enterprise
features we need.

Once all these critical features are there it's a good time to take a big
step
back and re-evaluate the archtecture and all it's aspects by taking into
account the big picture which involves all the functionality.

There are some good reasons for this.

(1) The architecture does not change considerably with each feature addition
so
familarity is not lost among the team members.  This stuff is hard to begin
with
and changes made every month might lead to the reintroduction of learning
curves
which consumes time.

(2) Migrations to newer versions are less painful for embedders and users
alike.

(3) We save big refactoring steps until more than one person can do them so
there
is more input into the process.  More eyes make for better decisions.  When
we
focus on refactoring and only that for a release we can summarize these
architectural
changes and track them by version.  Otherwise everything is just jumbled up
together.

(4) Until we take a step back and evaluate the big picture it's hard to know
what is a good decision and what pushes us further away from the best
decisions for refactoring the server to accommodate all aspects.  If we try
to refactor while working on a feature we're somewhat biased towards the
feature being added.  It's best to be minimalistic in terms of the amount of
change induced to add a feature then step back to solve the infrastructure
problems objectively.

BTW you might feel that we need to stop now and refactor.  That's something
to consider too but then how do we know what messed up perterbations the
other critical features will impose on the newly refactored code.

Alex

On 3/15/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> On 3/15/07, Alex Karasulu <akarasulu@apache.org> wrote:
> > On 3/15/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > > On 3/15/07, Alex Karasulu <akarasulu@apache.org> wrote:
> > > > Ok so you basically have this LDAPConfiguration bean contained under
> the
> > > > ServerStartupConfiguration?  Meaning I would get and
> > set the
> > > > LDAPConfiguration bean on the ServerStartupConfiguration?
> > >
> > > I wouldn't put it under the ServerStartupConfiguration.  No point to,
> > > other than lashing two classes together.
> >
> > Then the user has to use another call to the spring factory thingy to
> get
> > this bean by name again.  Instead of having a centrally rooted
> configuration
> > heirarchy.
>
> OK, there is an extra call.  If we agree on the LdapConfiguration
> bean, then whether it is under the StartupConfig or not doesn't matter
> to me.
>
> > > Instead, the
> > > LdapConfiguration is read via Spring in server-main Service and used
> > > in the ServerContextFactory to start the LDAP protocol providers for
> > > LDAP and LDAPS.
> >
> > How does this effect the daemon bootstrappers?  Will the daemon code
> work
> > the same?
>
> Yeah, I have it working.  Works identically.
>
> > > The issue will be keeping
> > > protocol config consistent with the other 4 protocols we have.
> >
> > Hmmm I agree with the concept but I don't like this outcome.  Perhaps I
> > just need to see the mechanics of it.
> >
> > ServerStartupConfiguration is not just for LDAP but for all the services
> in
> > the
> > server.
>
> It's a minor point; they can all go under ServerStartupConfig.
>
> > > > Can you elaborate a tiny bit more on the configuration changes in
> the
> > doco
> > > > just so there are no questions?
> > >
> > > Elaborate as to what, specifically?
> >
> > Just verbally put down what you've changed.  A summary of it.  What was.
> > What's different now instead of just a configuration snippet.  Others
> > looking at this doco will not have a clue right?  Think with the
> perspective
> > of someone new trying to dive in and get involved.  Provide enough
> context
> > so they understand what you did.
> >
> > Makes sense?  You're leaving a trail this way so others can follow
> what's
> > going on and how we got there.
>
> Gotcha.  "Elaborate" was just a little broad.
>
> Enrique
>

Mime
View raw message