+1 on the MINA decoupling and the package + module renaming to ldap-api. But could you give us a detailed idea of what this will look like in terms of the package space. I ask this because it would be nice to have the ldap-api isolated so that it can be a simple OSGi bundle that can be reused and bound to implementation bundles at runtime for connections etc.


On Tue, Sep 14, 2010 at 1:27 AM, Kiran Ayyagari <kayyagari@apache.org> wrote:
On Tue, Sep 14, 2010 at 3:57 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>  On 9/13/10 11:44 PM, Kiran Ayyagari wrote:
>> On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny<elecharny@gmail.com>
>>  wrote:
>>> * asn1-codec should be merged with the client-api, and all the parts that
>>> are related to MINA (the best would be to abstract completely this part
>>> from
>>> MINA, in order to be able to switch the network layer)
>> this abstraction layer gets complicated as we dig through, IMHO I would
>> say
>> let us leave it as it is, we are not gonna change our network layer
>> anyway in the near
>> future. We are happy with MINA, aren't we?
> Let me explain what I see as an issue : currently, shared-ldap depends on
> MINA even if we don't use MINA at all (like Studio which is currently using
> JNDI). Why would someone using only this part has to embed MINA too ?
> Also the only link we have with mina here is because the LdapProtocolEncoder
> is implementing a MINA class to encode a message. Nowhere in shared do we
> call the encode method.
> This is what I'd like to get rid of.
ahhh, I see where the issue is, I had the same problem when I wanted
to implement a new
LdapConnection with a different transport without using MINA but I
ended up bunding MINA
dependency too.

+1 for a abstraction layer

Kiran Ayyagari

Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu