[classlib][ldap] Several development concerns about Ldap service provider

[Spark Shen <sm...@gmail.com>]

We had some discussions[1] with developers in Apache DS community. And find
they have existing sharable classes.
http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/

These classes constitute 3 major features.
1. codec - encode/decode ldap message
2. filter - parsing search filters such as 'cn=*'
3. schema - parsing schema

I prefer to include them into our project instead of re-implement.

We do have problems. So far, I can see at least 2 problems:

1. Dependency: How should we include those code from Apache DS. Using binary
jars as Yoko, or SVN external link as our concurrent module.
Both of the methods will have its pro & con. Binary form will involve more
manual efforts, while external link may potentially pollute our code base.

2. Code duplication: Apache DS have classes which will duplicate our code. A
simple example is LdapDN. Shall we adapt our implementation to their code?
Any comments?

[1]http://www.nabble.com/-OT--Is-studio-using-Sun'
s-ldap-service-provider--t4376387.html
-- 
Spark Shen
China Software Development Lab, IBM

Re: [classlib][ldap] Several development concerns about Ldap service provider

[Regis <xu...@gmail.com>]

Stepan Mishura wrote:
> On 9/7/07, Spark Shen <sm...@gmail.com> wrote:
>> We had some discussions[1] with developers in Apache DS community. And find
>> they have existing sharable classes.
>> http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/
>>
>> These classes constitute 3 major features.
>> 1. codec - encode/decode ldap message
>> 2. filter - parsing search filters such as 'cn=*'
>> 3. schema - parsing schema
>>
>> I prefer to include them into our project instead of re-implement.
>>
>> We do have problems. So far, I can see at least 2 problems:
>>
>> 1. Dependency: How should we include those code from Apache DS. Using binary
>> jars as Yoko, or SVN external link as our concurrent module.
>> Both of the methods will have its pro & con. Binary form will involve more
>> manual efforts, while external link may potentially pollute our code base.
>>
>> 2. Code duplication: Apache DS have classes which will duplicate our code. A
>> simple example is LdapDN. Shall we adapt our implementation to their code?
>> Any comments?
>>
> 
> Sharing the code is a good thing. But from the first glance common
> parts are quite differ. And I have no idea how much efforts are
> required for the code adaptation.
the main duplicate parts is from org.apache.harmony.jndi.internal.parser 
package, which support to implement javax.naming.ldap.LdapName, 
javax.naming.ldap.Rdn and a name parser for ldap, they are relative 
independent and rarely used by other code, so i think there is not much 
work for code adaptation.

Best regards,
Regis.

> 
> I don't details of Apache DS and Ldap service provider. So naive
> approach may be to take Apache DS binaries and develop wrapper(s) to
> be used by Harmony ldap service provider.
> 
> Thanks,
> Stepan.
> 
>> [1]http://www.nabble.com/-OT--Is-studio-using-Sun'
>> s-ldap-service-provider--t4376387.html
>> --
>> Spark Shen
>> China Software Development Lab, IBM
>>
> 

Re: [classlib][ldap] Several development concerns about Ldap service provider

[Stepan Mishura <st...@gmail.com>]

On 9/7/07, Spark Shen <sm...@gmail.com> wrote:
> We had some discussions[1] with developers in Apache DS community. And find
> they have existing sharable classes.
> http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/
>
> These classes constitute 3 major features.
> 1. codec - encode/decode ldap message
> 2. filter - parsing search filters such as 'cn=*'
> 3. schema - parsing schema
>
> I prefer to include them into our project instead of re-implement.
>
> We do have problems. So far, I can see at least 2 problems:
>
> 1. Dependency: How should we include those code from Apache DS. Using binary
> jars as Yoko, or SVN external link as our concurrent module.
> Both of the methods will have its pro & con. Binary form will involve more
> manual efforts, while external link may potentially pollute our code base.
>
> 2. Code duplication: Apache DS have classes which will duplicate our code. A
> simple example is LdapDN. Shall we adapt our implementation to their code?
> Any comments?
>

Sharing the code is a good thing. But from the first glance common
parts are quite differ. And I have no idea how much efforts are
required for the code adaptation.

I don't details of Apache DS and Ldap service provider. So naive
approach may be to take Apache DS binaries and develop wrapper(s) to
be used by Harmony ldap service provider.

Thanks,
Stepan.

> [1]http://www.nabble.com/-OT--Is-studio-using-Sun'
> s-ldap-service-provider--t4376387.html
> --
> Spark Shen
> China Software Development Lab, IBM
>

Re: [classlib][ldap] Several development concerns about Ldap service provider

[Regis <xu...@gmail.com>]

Yang Paulex wrote:
> does ApacheDS provides a separated binaries jars for these features
> harmony needs? Or we need to build them oursleves? If it's latter
Yes, there are separated binaries jars in maven repository at [1], it's 
up to date.
we just need shared-ldap and shared-asn1 modules, which depends on antlr,
commons-collections and slf4j, they also can be found in maven repository.

[1] http://repo1.maven.org/maven2/org/apache/directory/shared/

Best Regards,
Regis.

> case, is it possible to separate these codes from other parts of
> ApacheDS?
> 
> On 9/7/07, Regis <xu...@gmail.com> wrote:
>> Spark Shen wrote:
>>> We had some discussions[1] with developers in Apache DS community. And
>> find
>>> they have existing sharable classes.
>>>
>> http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/
>>> These classes constitute 3 major features.
>>> 1. codec - encode/decode ldap message
>>> 2. filter - parsing search filters such as 'cn=*'
>>> 3. schema - parsing schema
>>>
>>> I prefer to include them into our project instead of re-implement.
>>>
>>> We do have problems. So far, I can see at least 2 problems:
>>>
>>> 1. Dependency: How should we include those code from Apache DS. Using
>> binary
>>> jars as Yoko, or SVN external link as our concurrent module.
>>> Both of the methods will have its pro & con. Binary form will involve more
>>> manual efforts, while external link may potentially pollute our code base.
>> I prefer to use binary jars, because the interface and methods we used
>> should be stable, use SVN external link may make our code in unstable
>> position.
>>
>> ApacheDS also depends on some jars, such as common-lang, antlr, if they
>> can provide the whole package is the best.
>>> 2. Code duplication: Apache DS have classes which will duplicate our code.
>> A
>>> simple example is LdapDN. Shall we adapt our implementation to their code?
>>> Any comments?
>> seems ApackeDS' implementation can't avoid, so we should use theirs as
>> more as possible, if there is no way to avoid using both implementations
>> simultaneous, adaptor would be helpful.
>>> [1]http://www.nabble.com/-OT--Is-studio-using-Sun'
>>> s-ldap-service-provider--t4376387.html
> 
> 

Re: [classlib][ldap] Several development concerns about Ldap service provider

[Spark Shen <sm...@gmail.com>]

2007/9/9, Yang Paulex <pa...@gmail.com>:
>
> does ApacheDS provides a separated binaries jars for these features
> harmony needs? Or we need to build them oursleves? If it's latter
> case, is it possible to separate these codes from other parts of
> ApacheDS?


It is the latter case.  I think we can seperate them.

Those codes are in a shared folder.
IMO, they are shared by client(DS studio) and server(DS), and they are
highly probably resides in a standalone module.
Problem is, they may rely on many other third-party jars. That may further
complicate our code base or dependencies.

On 9/7/07, Regis <xu...@gmail.com> wrote:
> >
> > Spark Shen wrote:
> > > We had some discussions[1] with developers in Apache DS community. And
> > find
> > > they have existing sharable classes.
> > >
> >
> http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/
> > >
> > > These classes constitute 3 major features.
> > > 1. codec - encode/decode ldap message
> > > 2. filter - parsing search filters such as 'cn=*'
> > > 3. schema - parsing schema
> > >
> > > I prefer to include them into our project instead of re-implement.
> > >
> > > We do have problems. So far, I can see at least 2 problems:
> > >
> > > 1. Dependency: How should we include those code from Apache DS. Using
> > binary
> > > jars as Yoko, or SVN external link as our concurrent module.
> > > Both of the methods will have its pro & con. Binary form will involve
> more
> > > manual efforts, while external link may potentially pollute our code
> base.
> > I prefer to use binary jars, because the interface and methods we used
> > should be stable, use SVN external link may make our code in unstable
> > position.
> >
> > ApacheDS also depends on some jars, such as common-lang, antlr, if they
> > can provide the whole package is the best.
> > >
> > > 2. Code duplication: Apache DS have classes which will duplicate our
> code.
> > A
> > > simple example is LdapDN. Shall we adapt our implementation to their
> code?
> > > Any comments?
> > seems ApackeDS' implementation can't avoid, so we should use theirs as
> > more as possible, if there is no way to avoid using both implementations
> > simultaneous, adaptor would be helpful.
> > >
> > > [1]http://www.nabble.com/-OT--Is-studio-using-Sun'
> > > s-ldap-service-provider--t4376387.html
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>



-- 
Spark Shen
China Software Development Lab, IBM

Re: [classlib][ldap] Several development concerns about Ldap service provider

[Yang Paulex <pa...@gmail.com>]

does ApacheDS provides a separated binaries jars for these features
harmony needs? Or we need to build them oursleves? If it's latter
case, is it possible to separate these codes from other parts of
ApacheDS?

On 9/7/07, Regis <xu...@gmail.com> wrote:
>
> Spark Shen wrote:
> > We had some discussions[1] with developers in Apache DS community. And
> find
> > they have existing sharable classes.
> >
> http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/
> >
> > These classes constitute 3 major features.
> > 1. codec - encode/decode ldap message
> > 2. filter - parsing search filters such as 'cn=*'
> > 3. schema - parsing schema
> >
> > I prefer to include them into our project instead of re-implement.
> >
> > We do have problems. So far, I can see at least 2 problems:
> >
> > 1. Dependency: How should we include those code from Apache DS. Using
> binary
> > jars as Yoko, or SVN external link as our concurrent module.
> > Both of the methods will have its pro & con. Binary form will involve more
> > manual efforts, while external link may potentially pollute our code base.
> I prefer to use binary jars, because the interface and methods we used
> should be stable, use SVN external link may make our code in unstable
> position.
>
> ApacheDS also depends on some jars, such as common-lang, antlr, if they
> can provide the whole package is the best.
> >
> > 2. Code duplication: Apache DS have classes which will duplicate our code.
> A
> > simple example is LdapDN. Shall we adapt our implementation to their code?
> > Any comments?
> seems ApackeDS' implementation can't avoid, so we should use theirs as
> more as possible, if there is no way to avoid using both implementations
> simultaneous, adaptor would be helpful.
> >
> > [1]http://www.nabble.com/-OT--Is-studio-using-Sun'
> > s-ldap-service-provider--t4376387.html
>


-- 
Paulex Yang
China Software Development Lab
IBM

Re: [classlib][ldap] Several development concerns about Ldap service provider

[Regis <xu...@gmail.com>]

Spark Shen wrote:
> We had some discussions[1] with developers in Apache DS community. And find
> they have existing sharable classes.
> http://svn.apache.org/viewvc/directory/shared/trunk/ldap/src/main/java/org/apache/directory/shared/ldap/
> 
> These classes constitute 3 major features.
> 1. codec - encode/decode ldap message
> 2. filter - parsing search filters such as 'cn=*'
> 3. schema - parsing schema
> 
> I prefer to include them into our project instead of re-implement.
> 
> We do have problems. So far, I can see at least 2 problems:
> 
> 1. Dependency: How should we include those code from Apache DS. Using binary
> jars as Yoko, or SVN external link as our concurrent module.
> Both of the methods will have its pro & con. Binary form will involve more
> manual efforts, while external link may potentially pollute our code base.
I prefer to use binary jars, because the interface and methods we used 
should be stable, use SVN external link may make our code in unstable 
position.

ApacheDS also depends on some jars, such as common-lang, antlr, if they 
can provide the whole package is the best.
> 
> 2. Code duplication: Apache DS have classes which will duplicate our code. A
> simple example is LdapDN. Shall we adapt our implementation to their code?
> Any comments?
seems ApackeDS' implementation can't avoid, so we should use theirs as 
more as possible, if there is no way to avoid using both implementations 
simultaneous, adaptor would be helpful.
> 
> [1]http://www.nabble.com/-OT--Is-studio-using-Sun'
> s-ldap-service-provider--t4376387.html