You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@apache.org> on 2007/09/26 11:57:32 UTC
[Roadmap]Apache Directory Server 2.0 Roadmap proposal
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
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
Yep I agree with the addition of these features as well. I think we're
going out into Q2 though now.
We just don't have the resources to add all these capabilities properly by
the end of the perhaps.
Don't know.
We need more committers :).
Alex
On 9/26/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> We discussed about Virtual attributes, too. Seems to fit into 2.0.
>
> I would also have a way to restore a database in a consistent state
> after a crash.
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Emmanuel Lecharny <el...@gmail.com>.
We discussed about Virtual attributes, too. Seems to fit into 2.0.
I would also have a way to restore a database in a consistent state
after a crash.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
I don't know how critical but perhaps we should also make sure we have a
scheduler service
exposed so administrators can enable jobs for like backups or various other
operations. We
already use quartz in mitosis but it would be really nice to centralize
access to this service
from the DirectoryService interface. We don't need to go all out and back
the store in LDAP
for now although that would be nice but just having a scheduler even if the
job information is
maintained in memory using our server.xml for configuration is enough.
Do others think this should be added?
Alex
On 9/26/07, Emmanuel Lecharny <el...@apache.org> 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
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Ersin Er <er...@gmail.com>.
On 9/26/07, Alex Karasulu <ak...@apache.org> wrote:
>
> Keep in mind that as I respond I have one thing in mind which was
> discussed pretty often
> regarding this 2.0 offering as a stable enterprise usable release whereas
> 1.0 really did not
> cut it. So enterprise grade features are a key factor in delivering 2.0and this was something
> that we kept in mind while just discussing this road map.
>
> More inline ...
>
> On 9/26/07, Ersin Er <ersin.er@gmail.com > wrote:
>
> > On 9/26/07, Emmanuel Lecharny < elecharny@apache.org> wrote:
> >
>
> SNIP ...
>
> * ???password policy??? {5d}
>
>
> not so easy to implement. and also we want to wait for Kurt's RFC draft
> for this.
>
> Yes this is not easy to implement but I think you mean "implement
> correctly".
>
Of course my context was the roadmap. We maynot be able to implement it
correctly before 2008 Q1 (as Emmanuel proposed). And I would like to see at
least the initial draft from Kurt. One other way is to implement the most
correct system we think and make it pluggable. So we can include Kurt's
proposal in another release.
Perhaps
> we can try our best to infer what Kurt and others have already discussed
> for this capability
> with the admin model in mind. Keeping our sites on the bare minimum to
> offer something
> along the lines of this enterprise critical feature is something we can
> do. If the feature
> is kept minimal yet designed to be extensible we can expand on it to align
> better with the
> draft and RFC to follow in the future.
>
> The bottom line is you need password policy management in any LDAP server
> bound for
> use in the enterprise. Otherwise we need to give up the notion that 2.0is viable which
> really is OK by me. If we're not ready we're not ready: according to the
> Rolling Stones,
> "you can't always get what you want."
>
> * finish stored procedure semantics {20d}
> > * finish trigger support {20d}
>
>
> these both need to be handled with the standardization process. they
> should be included if and only if they are at least supported by a draft.
>
> Again Ersin I think you would prefer to take these features slowly over
> generations. However we
> have some of this already in place and just need more tweaking. It can be
> made to slowly align with
> the draft as well.
>
> These features give a degree of freedom for us to solve a slew of problems
> encountered in LDAP. If
> they are not present and stabilized although not final we've wasted a lot
> of energy in formulating them.
>
> * support for all schema entities {20d}
> > - nameForms
> > - ditContentRules
> > - ditStructureRules
>
>
> not so critical.
>
> Completing the schema subsystem is pretty critical IMO. These constructs
> enable constraining
> the DIT like making sure the right RDN attributes are used for a
> structural objectClass or the proper
> subordination is taking place as well as which auxiliary objectClasses can
> be added to certain
> structural objectClasses.
>
I haven't seen much demand on these features yet. Nobody on the list asked
for these features and I think they are not being practically used. It's
nice to have but not urgent for IMO.
These constraints can be solved with triggers too but why not get people
> understanding and using
> the features built into LDAP schema to handle these matters properly.
> Futhermore these will enable
> studio to provide better tooling for schema and directory design
> capabilities.
>
> Furthermore we seriously need object to LDAP mapping capabilities, these
> schema elements are
> critical cues for inferring PK relations in the DIT as well as a means to
> mapping objects to entries and
> how subordination is managed. To progress to the next level we must
> enable them and have our
> tooling support these schema constructs.
>
> * make critical schema flag (READ-ONLY) {3d}
> > * authz manager schema {15d}
>
>
> triplesec?
>
> This schema needs to be redesigned. I talked to E and others and they
> think we should just keep the
> schema in ApacheDS. Perhaps we don't have to. Tsec is lagging behind ADS
> now and it might be
> better to just add this into ADS for now. Don't know for sure but you
> have a good point.
>
> * 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}
>
>
> if it's simply a log interceptor it does not have to be part of the
> release. it can be released later and can be integrated with the server with
> for another release.
>
> Well the change log feature is something we wanted to solve some of our
> issues with incremental builds
> where the integration tests were slowing us down. This feature would
> enable us to rollback the server to
> earlier state instead of shutting down, cleaning up and restarting the
> server every time. This will just save
> us a serious amount of time collectively and is a smart move. But in
> addition to this the feature is very
> valuable from an auditing perspective and that is a big issue for
> enterprise deployment.
>
> I'm not saying we go full featured on this but we need at least something.
>
> Alex
>
>
--
Ersin Er
http://www.ersin-er.name
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
Keep in mind that as I respond I have one thing in mind which was discussed
pretty often
regarding this 2.0 offering as a stable enterprise usable release whereas
1.0 really did not
cut it. So enterprise grade features are a key factor in delivering 2.0 and
this was something
that we kept in mind while just discussing this road map.
More inline ...
On 9/26/07, Ersin Er <er...@gmail.com> wrote:
> On 9/26/07, Emmanuel Lecharny < elecharny@apache.org> wrote:
>
SNIP ...
* ???password policy??? {5d}
not so easy to implement. and also we want to wait for Kurt's RFC draft for
this.
Yes this is not easy to implement but I think you mean "implement
correctly". Perhaps
we can try our best to infer what Kurt and others have already discussed for
this capability
with the admin model in mind. Keeping our sites on the bare minimum to
offer something
along the lines of this enterprise critical feature is something we can do.
If the feature
is kept minimal yet designed to be extensible we can expand on it to align
better with the
draft and RFC to follow in the future.
The bottom line is you need password policy management in any LDAP server
bound for
use in the enterprise. Otherwise we need to give up the notion that 2.0 is
viable which
really is OK by me. If we're not ready we're not ready: according to the
Rolling Stones,
"you can't always get what you want."
* finish stored procedure semantics {20d}
> * finish trigger support {20d}
these both need to be handled with the standardization process. they should
be included if and only if they are at least supported by a draft.
Again Ersin I think you would prefer to take these features slowly over
generations. However we
have some of this already in place and just need more tweaking. It can be
made to slowly align with
the draft as well.
These features give a degree of freedom for us to solve a slew of problems
encountered in LDAP. If
they are not present and stabilized although not final we've wasted a lot of
energy in formulating them.
* support for all schema entities {20d}
> - nameForms
> - ditContentRules
> - ditStructureRules
not so critical.
Completing the schema subsystem is pretty critical IMO. These constructs
enable constraining
the DIT like making sure the right RDN attributes are used for a structural
objectClass or the proper
subordination is taking place as well as which auxiliary objectClasses can
be added to certain
structural objectClasses.
These constraints can be solved with triggers too but why not get people
understanding and using
the features built into LDAP schema to handle these matters properly.
Futhermore these will enable
studio to provide better tooling for schema and directory design
capabilities.
Furthermore we seriously need object to LDAP mapping capabilities, these
schema elements are
critical cues for inferring PK relations in the DIT as well as a means to
mapping objects to entries and
how subordination is managed. To progress to the next level we must enable
them and have our
tooling support these schema constructs.
* make critical schema flag (READ-ONLY) {3d}
> * authz manager schema {15d}
triplesec?
This schema needs to be redesigned. I talked to E and others and they think
we should just keep the
schema in ApacheDS. Perhaps we don't have to. Tsec is lagging behind ADS
now and it might be
better to just add this into ADS for now. Don't know for sure but you have
a good point.
* 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}
if it's simply a log interceptor it does not have to be part of the release.
it can be released later and can be integrated with the server with for
another release.
Well the change log feature is something we wanted to solve some of our
issues with incremental builds
where the integration tests were slowing us down. This feature would enable
us to rollback the server to
earlier state instead of shutting down, cleaning up and restarting the
server every time. This will just save
us a serious amount of time collectively and is a smart move. But in
addition to this the feature is very
valuable from an auditing perspective and that is a big issue for enterprise
deployment.
I'm not saying we go full featured on this but we need at least something.
Alex
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Ersin Er <er...@gmail.com>.
A few comments below..
(I am a little bit busy so excuse me for short comments.)
On 9/26/07, Emmanuel Lecharny <el...@apache.org> 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}
just a matter of fixing a serious bug with ACIs and filter handling
mechanism.
* ???password policy??? {5d}
not so easy to implement. and also we want to wait for Kurt's RFC draft for
this.
* finish stored procedure semantics {20d}
> * finish trigger support {20d}
these both need to be handled with the standardization process. they should
be included if and only if they are at least supported by a draft.
* 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
not so critical.
* make critical schema flag (READ-ONLY) {3d}
> * authz manager schema {15d}
triplesec?
* 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}
if it's simply a log interceptor it does not have to be part of the release.
it can be released later and can be integrated with the server with for
another release.
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
>
--
Ersin Er
http://www.ersin-er.name
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Chris Custine <cc...@apache.org>.
At this point I think this sounds like its probably the right thing to
do... I am already looking at the OSGi part and I really want to catch up
to Guillaume on the ServiceMix project because they have strikingly similar
OSGi requirements and I want to try to work with them on some of the
infrastructure pieces that we can share.
Lets go for it.
Chris
On 9/28/07, Emmanuel Lecharny <el...@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 <ak...@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 <el...@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 <ak...@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
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
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 <el...@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 <ak...@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 <el...@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 <ak...@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
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
That sounds insanely useful Chris. Deploying stored procedures of any
language as an OSGi bundle is very appealing.
BTW I have to one day explore this coupled with how to manage security so
code can be sandboxed based on the identity
of the executor.
Alex
On 9/28/07, Chris Custine <cc...@apache.org> wrote:
>
> Hi Guys,
> I started looking at scripting this week as well and wanted to point to Apache
> BSF <http://jakarta.apache.org/bsf/> which I am thinking about using in
> another project to support scripting in various languages such as Ruby
> (JRuby), Groovy, and Javascript (Rhino). Apparently the javax.scriptaddition to Java
> 1.6 was based partially on BSF, and if we use BSF we can still support
> scripting in 1.5. FWIW, I am planning to make an OSGi bundle that will
> allow deployment and registration of script packages as OSGi bundles so this
> may also benefit us later in some fashion.
>
> So I would be glad to help with the Stored Procs and Scripting in
> particular as well.
>
> Thanks,
> Chris
>
>
> On 9/28/07, Stefan Zoerner < stefan@labeo.de> wrote:
> >
> > Alex Karasulu wrote:
> > > * Support for Scripting languages for Stored Procedures (e.g.
> > Groovy)
> > >
> > >
> > > This also would be really cool to have. We just need more
> > participation
> > > on getting stored procedures
> > > implemented properly. It would be great if you could lend a hand if
> > it
> > > interests you of course.
> >
> > It seems that it is not much code we talk about. I am interested.
> >
> > Perhaps I'll start with my own implementation of StoredProcEngine for
> > Groovy in order to get my feet wet. If it works, perhaps Ersin can
> > review it and we can think about adding the code to support Groovy SPs
> > natively.
> >
> > Greetings,
> > Stefan
> >
> >
> >
> >
> >
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Chris Custine <cc...@apache.org>.
Hi Guys,
I started looking at scripting this week as well and wanted to point to Apache
BSF <http://jakarta.apache.org/bsf/> which I am thinking about using in
another project to support scripting in various languages such as Ruby
(JRuby), Groovy, and Javascript (Rhino). Apparently the
javax.scriptaddition to Java
1.6 was based partially on BSF, and if we use BSF we can still support
scripting in 1.5. FWIW, I am planning to make an OSGi bundle that will
allow deployment and registration of script packages as OSGi bundles so this
may also benefit us later in some fashion.
So I would be glad to help with the Stored Procs and Scripting in particular
as well.
Thanks,
Chris
On 9/28/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Alex Karasulu wrote:
> > * Support for Scripting languages for Stored Procedures (e.g.
> Groovy)
> >
> >
> > This also would be really cool to have. We just need more participation
> > on getting stored procedures
> > implemented properly. It would be great if you could lend a hand if it
> > interests you of course.
>
> It seems that it is not much code we talk about. I am interested.
>
> Perhaps I'll start with my own implementation of StoredProcEngine for
> Groovy in order to get my feet wet. If it works, perhaps Ersin can
> review it and we can think about adding the code to support Groovy SPs
> natively.
>
> Greetings,
> Stefan
>
>
>
>
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Stefan Zoerner <st...@labeo.de>.
Alex Karasulu wrote:
> * Support for Scripting languages for Stored Procedures (e.g. Groovy)
>
>
> This also would be really cool to have. We just need more participation
> on getting stored procedures
> implemented properly. It would be great if you could lend a hand if it
> interests you of course.
It seems that it is not much code we talk about. I am interested.
Perhaps I'll start with my own implementation of StoredProcEngine for
Groovy in order to get my feet wet. If it works, perhaps Ersin can
review it and we can think about adding the code to support Groovy SPs
natively.
Greetings,
Stefan
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
On 9/28/07, Stefan Zoerner <sz...@apache.org> wrote:
>
> * tgz-style "installer" (platform independent archive, like Tomcat for
> instance already has)
Yes this is a must. We should not release 2.0 without it.
* Support for Scripting languages for Stored Procedures (e.g. Groovy)
>
This also would be really cool to have. We just need more participation on
getting stored procedures
implemented properly. It would be great if you could lend a hand if it
interests you of course. Also I
started a draft for submission to the IETF on stored procedures and have
been talking to some folks
at OpenLDAP about it.
Alex
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Stefan Zoerner <sz...@apache.org>.
Emmanuel Lecharny wrote:
> 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 ?
I like the idea. It would help us to have a solid documentation for the
2.0, what ever the configuration style will be. And it would help to run
the certification effort smoothly with the related organizations.
And I have two things I would like to add to the road map for discussion
* tgz-style "installer" (platform independent archive, like Tomcat for
instance already has)
* Support for Scripting languages for Stored Procedures (e.g. Groovy)
Greetings from Hamburg,
Stefan
---8<---
Stefan Zoerner (szoerner@apache.org)
Committer :: PMC Member
Apache Directory Project
http://directory.apache.org
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 <ak...@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 <el...@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 <ak...@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
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
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 <el...@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 <ak...@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 <ak...@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 <da...@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
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Emmanuel Lecharny <el...@gmail.com>.
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 <ak...@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 <ak...@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 <da...@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
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
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 <ak...@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 <da...@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
> >
> >
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by Alex Karasulu <ak...@apache.org>.
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 <da...@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
>
>
Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Posted by David Jencks <da...@yahoo.com>.
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