directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject So what's next ?
Date Sun, 23 Dec 2012 11:53:54 GMT
Hi guys,

those last three months were quite busy ones, with a lot of added
features and bug fixes in the API, teh Server and Studio. The vote for
API 1.0.0-M14 and ApacheDS-M9 has just started, Studio 2.0-M4 will
follow shortly.

I'd like to list some of the missing parts we can work on next year. Not
all of them are critical, but in order to provide betetr products, it's
good to foresee what will be added soon.

The API :
---------

I think we don't have a lot of missing parts in the API.

o Referral : One thing that need to be added before we move to 1.0-RC1
is the Referral support. Right now, we just throw an exception when we
get a referral, leaving it to the end user to catch this exception, and
to do the call to the remote server. This is pretty minimal. We should
implement the referral chasing. That means we have to use another
conection to fetch results from remote servers. We also have a mechnaism
to detect cycles, which is a bit more complex. All in all, this should
not take months.

o OpenLDAP schema : We currently support either a local schema, or a
remote schema, assuming it's an ApacheDS schema. We ought to support at
least OpenLDAP schema, either local or remotely loaded. The number of
missing Synatx, MatchingRules and the associated SyntexCheckers,
Normalizers and Comparators are not that high. It's probably around 10
missing elements. Again, this should be easy to have

o AD schema : This is for a expected future : being able to support the
full AD schema would be a great addition to the API

o Check the various SASL algorithm : I *think* it works, I'm just not
sure we cover all the possible SASL mechanisms (especially the EXTERNAL one)

o Certificate support : Same here : we probably have a bit of work to
plainy leverage Certficates.

o Documentation : Well, just check the current ste, you'll know what we
have to complete :/

o JMX : I'd like to be able to expose some stats through JMX

o OSGi : The API is OSGi compliant, but we probably need to review what
has been done in this area.

o Controls and Extended operations : We currently support natively a few
of them. That would be good to have more Controls and Extended
operations supported.

o Schema Extension points : Same here. If one want to add a Syntax, a
MathcingRule or any related SchemaElement, we need to ease this
addition. It could be by improving the documentation.


The Server :
------------

There are a lot of things to work on. Although the server is now on
pretty good shape - in term of stability, usability and also performance
-, we have important missing parts.

o Crash Disaster Recovery : At the moment, we expect users to save the
content of the base periodically, knowing that a crashed server will not
be able to recover all the modified data since the last backup. Although
we have implemented a Journal that stores all the modified data, we
aren't leveraging this journal. It's mitigated by the fact that, with
replication, we should now be able to recover more easily from a crash,
but still, we depend on the remote server. This area is something we
must seriously address in the coming weeks.

o Bulk load : Load a huge number of entries in teh server is slow.
Really slow. Depending on the number of indexes, we can go down to max
200 entries added per second. It's a serialized area, we can only inject
entries one by one. The idea is to write a bulk load tool that order the
elements, loads them in the backend, and re-index everything. This is
really Backend dependent though. Storing entries in a LDIF partition is
totally different than storing them in a JDBM partition. We have to
focus on JDBM atm, as this is our main backend.

o ACI support : It's working, but it's far from being efficient. I
discovered that for every attribute of an entry being processed, and for
every value, we do a fetch in the backend (ok, with the cache, it's lss
an issue, but still). It's an area we hav'nt touch for years, and we
probably have to conduct a serious review.

o Schema : We don't support NameForm, DitControlRule, DitStructureRule
and MatchingRuleUse. This should be added.

o Schema Manager : We currently don't support modifications in the
schema. This should be added, assuming that if the backend contains
elements that are gong to be impacted by such modifications, we should
inform the user

o SP/Triggers : That's a great addition to the server, but due to the
huge modification we have done when we decided to use the LDAP API
instead of JNDI, it's not working anymore. It has to be fixed

o Replication : We need to do extensive tests. Many JIRAs have been
opened, I'm quite sure most of them are not anymore valid, but we have
to check them one by one.

o DeltaSyncrepl : This is something we have to work on

o JMX : Definitively a must have

o Cache : We have many caches in many places, it would be cool to have
one common cache where we register all the various caches.

o AdministrationModel : This is far from being perfect. We don't support
encapsulated Administrative Points.

o SubSchema : The current schema is attached to the rootDSE. It's not
supposed to be the case. We should be able to support more than one
schema, and attach them to the Schema AdministrativePoint. This is a lot
of work, but it's valuable.

o Performances/benchmarks : We need to conduct more tests. There are
area of improvement, but without a decent bench platform, it's hard to
shoot in the dark


I will stop here, I haven't listed Studio expected enhancements,
Pierre-Arnaud knows betetr that I do.

Those are the points that come to my mind, I'm sure there are many
other, so feel free to complete this long list !

Happy Christmas !

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com 


Mime
View raw message