directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Summer of Code Application
Date Tue, 14 Jun 2005 00:34:02 GMT
Alex, what a mail ! This is almost a roadmap for the next three
years :-)

On Mon, 2005-06-13 at 19:40 -0400, Alex Karasulu wrote:
> WRT to JDBM I agree its been lagging and is slow especially on writes 
> but this is ok.  I think there are more efficient ways we can be using 
> JDBM too however that needs more exploration.  

JDBM seems to work well, but at a point it will need to be brought back
to life as an open source project. 

> Regardless we have yet another option since backends are pluggable: using 
> SleepyCat's JE in place of JDBM.  

I don't konw if SleepyCat's licence allow us to embed it into an Apache
project, but at least we can offer an interface. This would be very cool
to have an abstract layer above two kind of database : BTree based
databases and standard relational database (Postgresql, ...)


> ASN.1 Libraries
> ==========

<snip/>

> 2). Stub compiler
> 
> Some theories and experiments but we're still deciding on the direction. 

Lot of work has to be done... The next version of LDAP ASN.1 codec will
be a step in this direction, and could perfectly well fit with a
compiler.

I will add that we also need two things :

4) A tool to test codec (basically, we need to implement something that
takes a PDU and the expecting decoded value, and checks that the
decoding generates the expected value). It could be XML based.

5) A proxy which shows incoming requests and outgoing responses. Cool to
debug LDAP exchanges. 

> People interested in ASN.1 (BER and DER encoding) and a stub compiler 
> should connect with Emmanuel Lecharny and Alan Cabrera. 

No pb ! (Emmanuel)

> LDAP Agenda, Direction, Road map etc ...
> =========================

> 3). Possible replacement for AspectJ. 

Do we need AspectJ ?

> 6). Better transaction management and ACIDity instead of using buffer 
> cache like mechanism with synch method calls

Definitively. And we will need it deadly if dealing with replication !

> 11). Better error handling and easily understood messages

+1 :)

> 12). Logging
> 
> I personally did a poor job of this  To my credit much of the logging 
> lines were added and removed while moving from one IoC container to the 
> next during the Avalon days. 

We have to decide which login mechanism we will use, should it be log4j
or Java log. 


I would like to add some items to Alex's list :

18) JMX. 
The ApacheDS need to me managed, and JMX is the Java way to do it. I
don't know how long it could take to extend MC4J to handle an ApacheDS
server...

19) Replication

This is something that need to be somwhere in the ApacheDS landscape.
There were some discussion on the dev-list, but I didn't had time to
check where we are going on this subject.

20) Samples
It could be very cool to have some 'real life' samples. Not just ten
entries, but something like 10K entries, with images, and not a flat
tree.

21) Performances/Benchmark
We don't have any benchmark available (expect micro-benchmark). It would
be valuable to expose a performance test to see what king of beast
ApacheDS really is !



Thanks a lot Alex for all these items you added! That's a hudge
roadmap !

Emmanuel L├ęcharny



Mime
View raw message