On Fri, Apr 10, 2009 at 11:32 AM, Emmanuel Lecharny <email@example.com> wrote:
Alex Karasulu wrote:I agree. I think that at some point, we were so focused to get 2.0 out that we dismissed any reorganization.
I've been looking at the packages in the apacheds project and as you can
imagine many things grew wild out of short term efforts to get things done.
Before we move forward with a 2.0 and even sooner before considering any
kind of use for OSGi we need to clean up this package structure and have
some order. From then on we can take care in how we organize things.
I think we also have to check if we really need some of the interfaces we have, when there is only one implementation...
I'd like to open a discussion about how best to organize our package
structure. I'll seed it by listing my objectives:
(1) cleanup unused modules and packages
(2) split out interfaces from implementations into their own packages and
(3) have a consistent scheme for naming and allocating sub packages under
o.a.d.server.core and o.a.d.server
Our inherent policy was to use o.a.d.server.core.* for packages associated
with the DirectoryService which did not require any network access. It was
for everything needed to store and manage LDAP entries and conduct LDAP
operations on them without having to go over the wire. The o.a.d.server.*
packages minus o.a.d.server.core.* was for anything above this layer that
depended on it and used some kind of networking like the LdapService and the
AuthenticationService (in the protocol-kerberos module).
Over time with most developers working in this project this convention
started to get mixed up. I was wondering if this convention is worth
keeping or something beter can be proposed. If we keep this convention I
will cleanup and make sure everything follows it.
Next I would like to have a consistent naming scheme for the modules. Any
I think we should add a 'protocol' between 'server' and 'ldap'
It will be removed, and renamed to syncrepl. Now, should it be part of core ?
Why is xdbm not part of core ?xdbm-base