harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Spark Shen" <smallsmallor...@gmail.com>
Subject Re: [classlib][ldap] Several development concerns about Ldap service provider
Date Sun, 09 Sep 2007 08:37:17 GMT
2007/9/9, Yang Paulex <paulex.yang@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.regis@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message