Re: So what's next ?

[Emmanuel Lécharny <el...@gmail.com>]

Le 12/23/12 12:53 PM, Emmanuel Lécharny a écrit :
> 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 !
>
I would add a few tasks on the server :

o Dynamic configuration : a good addition

o Mavibot suport : it's a In-Memory MVCC Btree. Would be good to have it
as a partition

o Cross-Partition move : it's currently not supported

o Virtual Attributes : another good to have extension.

o Use byte[] instead of Value all over the server. It would save a lot
of CPU

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com