directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Date Wed, 26 Sep 2007 15:31:44 GMT
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

Mime
View raw message