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@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