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 =3D 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 :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* 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 :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
* 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 ?

--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com

[ Post a follow-up to this message ]

A few comments below..

(I am a little bit busy so excuse me for short comments.)

On 9/26/07, Emmanuel Lecharny <elecharny@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

[ Post a follow-up to this message ]

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 <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrot
e:

> On 9/26/07, Emmanuel Lecharny < elecharny-1oDqGaOF3Lkdnm+yROfE0A@public.gm
ane.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

[ Post a follow-up to this message ]

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 <elecharny-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:[vbc
ol=seagreen]
>
> 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
>[/vbcol]

[ Post a follow-up to this message ]

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.

--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com

[ Post a follow-up to this message ]

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 <elecharny-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:[vbc
ol=seagreen]
>
> 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
>[/vbcol]

[ Post a follow-up to this message ]

On 9/26/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.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.0an
d this was something
> that we kept in mind while just discussing this road map.
>
> More inline ...
>
> On 9/26/07, Ersin Er <ersin.er-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > w
rote:
> 
>
> 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} 
>
>
> 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} 
>
>
> 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} 
>
>
> 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 
>
>
> 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 wi
th
> 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

[ Post a follow-up to this message ]

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 =20
going into 2.0 but I would like to work on these features that based =20
on my experience I think will make both using and working on apacheds =20=

a lot more pleasant in the short term even if there may be better =20
long term solutions (e.g. configuration in DIT) or may require =20
existing users to adjust server customizations.

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

documentation for the configuration.

- gradually eliminate the *Configuration wrappers around server =20
components, starting with InterceptorConfiguration (DIRSERVER-1023).  =20=

This (at least for interceptors) isn't a giant code change but IMO =20
really improves the clarity of the code and makes it much easier to =20
change and work with.

- separate the operations of starting an embedded server from jndi.  =20
E.g., currently you feed a StartupConfiguration into the jndi =20
environment and some magic happens :-).  I don't have a clear idea =20
for the best replacement for this but one obvious possibility that =20
seems likely to work is to construct the running server directly in =20
code from the appropriate components and feed that into the jndi =20
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 =3D 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 :
>
> ----------------------------------------------------------------------=20=

> -------------------------
> 2.0 roadmap proposal
> ----------------------------------------------------------------------=20=

> -------------------------
> 1) Candidates by December 1st, release final by january 15th
>
>
> 2) tasks and durations
>
> Estimated Durations :
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> * add index rebuilding command to 1.5 {1d}
> * add change admin password command & not cleartext in server.xml =20
> 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 :
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> * 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 ...
>
> ----------------------------------------------------------------------=20=

> -------------------------
>
> 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 ?
>
> --=20
> Regards,
> Cordialement,
> Emmanuel L=E9charny
> www.iktek.com

[ Post a follow-up to this message ]

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-/E1597aS9LQAvxtiuMwx3w@public.gmane.org> wrote:[vbcol
=seagreen]
>
> 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:
> 
>
>[/vbcol]

[ Post a follow-up to this message ]

Hmmm... It's not a vote, it's a proposal.

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

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

On 9/27/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.org> wrote:
> Can we have some more people voting on this so we can get closure in a fe=
w
> hours?  Please
> if you hold binding votes use em any way you like but just vote.
>
> Alex
>
>
> On 9/27/07, Alex Karasulu <akarasulu-1oDqGaOF3Lkdnm+yROfE0A@public.gmane.o
rg> wrote: 
ure[vbcol=seagreen]
> and are things that 
on[vbcol=seagreen]
> IRC that we want 
> personally am giddy 
-[vbcol=seagreen]
> hence why I changed 
ce[vbcol=seagreen] 
he[vbcol=seagreen] 
op[vbcol=seagreen] 
a[vbcol=seagreen] 
is[vbcol=seagreen] 
s[vbcol=seagreen] 
,[vbcol=seagreen] 
a[vbcol=seagreen] 
,[vbcol=seagreen] 
to[vbcol=seagreen] 
> ---------------------------------------------------------------------- 
> ---------------------------------------------------------------------- 
low[vbcol=seagreen] 
> ---------------------------------------------------------------------- 
his[vbcol=seagreen] 
>
>


--=20
Regards,
Cordialement,
Emmanuel L=E9charny
www.iktek.com

[ Post a follow-up to this message ]