You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/09/13 23:40:47 UTC

Shared refactoring proposal

  Hi !

I would like to officially propose some more refactoring in the shared 
and API libraries :
- first, as the API is now officially part of shared, I think we should 
rename shared and the associated packages. We had some discussion about 
the new name, it seems that 'api' is probably the best. So every packahe 
like org.apache.directory.shared.xxx will be renamed to 
org.apache.directory.api.xxx
- second, some modules may be merged :

* asn1, cursor, i18n, ldap, ldap-constants, ldap-converter, ldap-jndi, 
ldap-schema, ldap-schema-loader, ldap-schema-manager and ldif should be 
merged in a single module (namely, ldap-api instead of shared-ldap)
* dsml-parser deserves a dedicated package
* 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)

Thoughts ?


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


Re: Shared refactoring proposal

Posted by Alex Karasulu <ak...@apache.org>.
+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.

Regards,

On Tue, Sep 14, 2010 at 1:27 AM, Kiran Ayyagari <ka...@apache.org>wrote:

> On Tue, Sep 14, 2010 at 3:57 AM, Emmanuel Lecharny <el...@gmail.com>
> wrote:
> >  On 9/13/10 11:44 PM, Kiran Ayyagari wrote:
> >>
> >> On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny<el...@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

Re: Shared refactoring proposal

Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Sep 14, 2010 at 3:57 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>  On 9/13/10 11:44 PM, Kiran Ayyagari wrote:
>>
>> On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny<el...@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

Re: Shared refactoring proposal

Posted by Emmanuel Lecharny <el...@gmail.com>.
  On 9/13/10 11:44 PM, Kiran Ayyagari wrote:
> On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny<el...@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.


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


Re: Shared refactoring proposal

Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Sep 14, 2010 at 3:10 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>  Hi !
>
> I would like to officially propose some more refactoring in the shared and
> API libraries :
> - first, as the API is now officially part of shared, I think we should
> rename shared and the associated packages. We had some discussion about the
> new name, it seems that 'api' is probably the best. So every packahe like
> org.apache.directory.shared.xxx will be renamed to
> org.apache.directory.api.xxx
> - second, some modules may be merged :
>
> * asn1, cursor, i18n, ldap, ldap-constants, ldap-converter, ldap-jndi,
> ldap-schema, ldap-schema-loader, ldap-schema-manager and ldif should be
> merged in a single module (namely, ldap-api instead of shared-ldap)
> * dsml-parser deserves a dedicated package
> * 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?

Kiran Ayyagari