directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Date Thu, 27 Sep 2007 21:25:06 GMT
Can we have some more people voting on this so we can get closure in a few
hours?  Please
if you hold binding votes use em any way you like but just vote.

Alex

On 9/27/07, Alex Karasulu <akarasulu@apache.org> wrote:
>
> 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.
>
> Alex
>
> On 9/27/07, David Jencks <david_jencks@yahoo.com> 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.
> >
> > thanks
> > 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
> > > www.iktek.com
> >
> >
>

Mime
View raw message