These changes in them selves will add clarity to the server's architecture and are things that
we also want to do.  For example the last point is something I told you on IRC that we want
to do desparately to decouple server internals from JNDI semantics so I personally am giddy
for you to be helping us.  You're the answer to a lot of my problems :) - hence why I changed
my vote to continue forward.


On 9/27/07, David Jencks <> wrote:
Repeatiing some of what I said on the Vote thread...

I don't expect to be able to help much with the actual ldap features
going into 2.0 but I would like to work on these features that based
on my experience I think will make both using and working on apacheds
a lot more pleasant in the short term even if there may be better
long term solutions (e.g. configuration in DIT) or may require
existing users to adjust server customizations.

- allow optional configuration using xbean-spring (DIRSERVER-984).
While allowing use of old-style server.xml this also lets users
configure the server according to a schema derived from the actual
server components.  IIRC the schema generation process also generates
documentation for the configuration.

- gradually eliminate the *Configuration wrappers around server
components, starting with InterceptorConfiguration (DIRSERVER-1023).
This (at least for interceptors) isn't a giant code change but IMO
really improves the clarity of the code and makes it much easier to
change and work with.

- separate the operations of starting an embedded server from jndi.
E.g., currently you feed a StartupConfiguration into the jndi
environment and some magic happens :-).  I don't have a clear idea
for the best replacement for this but one obvious possibility that
seems likely to work is to construct the running server directly in
code from the appropriate components and feed that into the jndi
environment.  As we get closer perhaps a better solution will appear.

david jencks

On Sep 26, 2007, at 2:57 AM, Emmanuel Lecharny wrote:

> Hi guys,
> it's more than 5 months we released 1.5.0, and nearly one month since
> 1.5.1. Keep in mind that 1.5 is supposed to be an unstable release,
> which means that we may add features to it. It has some impact on the
> way we are currently working :
> 1- as the 1.5 is officially released, and publicly available as a top
> project on our web-site, users may be confused about its status
> 2- we encouraged users to switch to 1.5, because we must admit that
> it's way faster and stable than 1.0
> 3- we are reluctant to add new features because it can negatively
> impact our users because of point (1) and (2)
> 4- we currently have no idea about which feature has to be included
> into the trunk, because we don't have any roadmap for a 2.0
> 5- and we also have a need of huge modifications which will differ a
> 2.0 to get out soon, if we introduce them into the trunk.
> For all these reasons, we do think that at this point, a clear (?)
> roadmap for 2.0 must be agreed on. [we = many people expressed this
> opinion]. The idea is to deliver a 2.0 by the end of this year. This
> is not as simple as it seems :
> - we have around 100 open issues
> - we have absolutly no idea about the number of users we have which
> may be impacted if we do change important things like configuration,
> schema handming and database format
> - we must go through some RC before releasing 2.0, and it will take a
> couple of months
> - we have to guarantee that we get the VSLDAP certification for 2.0 ,
> and if possible, with STANDARD level
> - and documentation must be updated.
> Better starting now with this roadmap if we don't want the release to
> be delivered by Q4 2008 ;)
> So here is a fisrt draft :
> ----------------------------------------------------------------------
> -------------------------
> 2.0 roadmap proposal
> ----------------------------------------------------------------------
> -------------------------
> 1) Candidates by December 1st, release final by january 15th
> 2) tasks and durations
> Estimated Durations :
> =============
> * add index rebuilding command to 1.5 {1d}
> * add change admin password command & not cleartext in server.xml
> file {5d}
> * add start tls code  {10d}
> * make mitosis work {20d}
> * ad (ldap) delegated authentication {10d}
> * make sure userPassword cannot be searched {2d}
> * ???password policy??? {5d}
> * finish stored procedure semantics {20d}
> * finish trigger support {20d}
> * add safeguards to prevent size based DoS attacks {5d}
> * add Jetty container {5d}
> * ???Controls???
>   (schema update control) {20d}
> * installers for Solaris and Debian {10d}
> * support for all schema entities {20d}
>    - nameForms
>    - ditContentRules
>    - ditStructureRules
> * make critical schema flag (READ-ONLY) {3d}
> * authz manager schema {15d}
> * only add m-usage-count attribute to meta schema for use later (allow
> updates to this by the server with USAGE) {3d}
> * Add a changeLog interceptor {10d}
> Unknown Durations :
> ============
> * documentation for 2.0 {?}
> * kill bug parade
> * ???encrypted attributes???
> * STANDARD certification {??}
> * ???fine grained disabling of schema checks???
>   (m-disableChecking BOOLEAN)
> * Packaging
> * Studio synchronization to deliver a suite
> 3) Roadmap :
> To be done ...
> ----------------------------------------------------------------------
> -------------------------
> This is a first list we established with Alex, so please consider this
> as a draft, please tell us what you think about it.
> Thoughts ?
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny