+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.
ahhh, I see where the issue is, I had the same problem when I wantedOn Tue, Sep 14, 2010 at 3:57 AM, Emmanuel Lecharny <email@example.com> wrote:
> On 9/13/10 11:44 PM, Kiran Ayyagari wrote:
>> On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny<firstname.lastname@example.org>
>>> * 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
>>> MINA, in order to be able to switch the network layer)
>> this abstraction layer gets complicated as we dig through, IMHO I would
>> 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.
to implement a new
LdapConnection with a different transport without using MINA but I
ended up bunding MINA
+1 for a abstraction layer