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 Fri, 28 Sep 2007 15:31:40 GMT
I'm totally on board with this.  Getting all we had done by December was
freaking me out a bit.
Also now we can relax a little and make architectural changes that were
proposed by several
who want to get more involved in the code base.

On 9/28/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> Hi all,
>
> I was thinking this morning in my bed (it's sooo good to stay a long
> time in a warm bed when the weather is cold and rainy :) that the
> deadline is totally unrealistic. Delivering a 2.0 release by dec or
> even jan is simply impossible.
>
> Here is what I would suggest :
> - let's release this 2.0 for Apache Conference EU (may)
> - let's add some more features :
> * OSGi ?
> * using Values to handle the streaming problem
> * decoupling the evaluation engine from the backend
> - let's also release bug fixes releases in the mean time (1.5.2, etc)
>
> wdyt ?
>
> On 9/28/07, Alex Karasulu <akarasulu@apache.org> wrote:
> > Shoot David told me that I put this on the wrong thread on IRC - sorry I
> > guess I was in a hurry heading out
> > the door.
> >
> > But yes I think we need to have the roadmap but let's allow some
> variability
> > for those that come
> > around and want to add a feature as we're adding these features. You
> also
> > never know when fixing
> > one thing we discover yet another task which needs to be handled.  But
> we
> > just need some good
> > faith agreement on it once we solidify the road map.
> >
> > Alex
> >
> >
> > On 9/27/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> > > 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
> > >
> >
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

Mime
View raw message