directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: [Roadmap]Apache Directory Server 2.0 Roadmap proposal
Date Thu, 27 Sep 2007 06:24:51 GMT
On 9/26/07, Alex Karasulu <> 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
> that we kept in mind while just discussing this road map.
> More inline ...
> On 9/26/07, Ersin Er < > wrote:
> > On 9/26/07, Emmanuel Lecharny <> 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.

> 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

View raw message