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][jndi] Integration of Ldap Service Provider and javax.naming.ldap package
Date Fri, 12 Oct 2007 06:15:59 GMT
2007/10/12, Osvaldo Demo <demoosvaldo@gmail.com>:
>
> Well, I'll explain the items that were not clear.
>
> > What does "container classes" means here?
>
> A "Container Class" is a class, a data structure, or an abstract data
> type (ADT) whose instances are collections of other objects. They are
> used to store objects in an organized way following specific access
> rules. Reference:
> http://en.wikipedia.org/wiki/Container_(data_structure)
>
> For instance, we are taking the SortControl Class which is an LDAP
> Control Extension for Server Side Sorting of Search Results as defined
> in RFC 2891. This class is a container class and is in charge of doing
> the necessary internal data manipulation without anyone from the
> outside seeing that.
>
> > I'm not sure what you means "Integration of Ldap Service Provider and
> > javax.naming.ldap package",
> > I think they are separated layer, implementation of service provider
> > should not depends on implementation
> > of the javax.naming.ldap package, so that harmony service provider can
> > also work with other jdk.
>
> The Ldap Service Provider is another layer, i agree with you, but
> there is a caveat to take into account. Particularly with the
> StartTlsRequest extension, we have to have a default Response to
> return. Sun's JDK returns it's own StartTlsResponse. I think that
> Harmony should return it's own too, and now is possible because we
> will have a service provider available.
>
> StartTlsRequest first checks on  the file
> "META-INF/services/javax.naming.ldap.StartTlsResponse", then if that
> file doesn't exists returns the default implementation.
>
> You can check see a description here:
>
> http://72.5.124.55/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html
>
> That's why i'm saying "integration with ldap package".
>
> > We are planning to implement it, and have done some work, if you are
> > interested, welcome to join us.
>
> Well, i'll be glad to help you with this. But i was hired by the ITC
> to implement the javax.naming.ldap package last year and now i'm
> working full time on another area (IT) in other company. I'm also
> working to complete my thesis. Besides, I'll do what i can in my free
> time.
>
> Do you have a server to hold the project files, cvs or subversion,
> documentation, etc?.
> Is there any schedule about the implementation?
> How many people is working on the project?
> What about testing procedures?
>
> Please send me any information that you consider that i need to know.


Hi Osvaldo Demo

I think you are just reminding us here that there are still work to be done
for ldap service provider.
The main work includes:

* An ASN1 Parser
* Dependence with javax.naming package
* Container classes
* StartTlsResponse Extension

Correct my if I am wrong.

The current status of ldap service provider is
1. Now we have an ASN1 framework used for encode/decode ldap messages (in
security/src/main/java/common/org/apache/harmony/security/asn1).  I think
that's what you mean by 'ASN1 parser'.
2. Bridge classes used to solve dependence with javax.naming package and
container classes are under development.
3. For secure communication with ldap server, we will use
javax.naming.ldap.StartTlsRequest to avoid duplicate code.
etc.

As far as I know, besides me, Rigis is also working on implementing this
feature. If you can give a hand, it would be even greater.
I think the most needed part is test cases. Do you have some ready ones?

Best regards

Best regards,
> Osvaldo Demo.
>



-- 
Spark Shen
China Software Development Lab, IBM

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