directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Date Thu, 27 Sep 2007 21:55:28 GMT
Hmmm... It's not a vote, it's a proposal.

But as soon as nobody has anything to add, I suggest that we close the
roadmap and vote about it.

What about launching a vote by the end of this week, so that everybody
can have a chance to add some needed features ?

On 9/27/07, Alex Karasulu <akarasulu@apache.org> wrote:
> 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
> > >
> > >
> >
> >
>
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message