Hello Alex/Emmanuel,

Thanks for your suggestions.

With all this discussion and information provided by you and some of the pointers searched on internet, I am interested in the proxy project and I think with the smart load balancer (more interested in this), failover mechanism, security features can make LDAP Proxy more robust.  btw, is developing a load blaancer a separate project idea for proxy project ?

Since I am new to ApacheDS project so at this moment its bit difficult for me to evaluate about the volume of work involved in this LDAP proxy project for gsoc (not sure how much work will be involved for about 3-month). In other words, what is the scope of the project (I think it needs to be defined based on the existing functionality for Proxy)?

Could you also let me know about the tools and technologies will be used like Java (i am sure about it!), Windows/Linux? or others?

Thanks again.

Best Regards,

On Wed, Mar 4, 2009 at 3:44 PM, Alex Karasulu <akarasulu@gmail.com> wrote:
Coming in late here but some other items that would be interesting would be:

  o New LDAP Client API based on entry API
      - new client implementation to replace using JNDI
  o ApacheDS command console using new mina SSH server
      - you ssh into ApacheDS to issue commands for managing it
  o Finish off object/class mapping for LDAP
      - Kiran has done some work here and this will be very useful down the line

BTW the proxy idea is great in as much has been discussed but I see some other opportunities with an LDAP proxy. Namely as a LDAP smart load balancer or switch.  Not many load balancers out there consider application layer (7) specifics, even less specifically are aware of LDAP issues when it comes to load balancing.  The proxy can help with that and can be a stand alone service.

You can do so much here:

  o distribute client connections based on a namingContext across replicas serving that context
  o distribute search requests based last similar request to take advantage of already populated cache - for example if I search for (uid=ra*) on replica A with client 1, then it makes sense to route the same search from client 2 to replica A if the same request is issued within some time threshold.  This way the cache in replica A containing for the index on uid can be used to perform the search faster etc.

I have a few of these ideas for an LDAP load balancer after some of my recent experiences working with production situations.  Might be a fun project that would produce something very useful in production.


On Tue, Mar 3, 2009 at 5:50 PM, Emmanuel Lecharny <elecharny@apache.org> wrote:
Rahul SOA wrote:
It was a Swing ui
 so that means it is not available in the current version of the Studio. Is

Is this enough for you as a description ?

Yes, by this time its enough. I have got some idea about the LDAP proxy
and I think it interests me more now. Moving on, do we already have decoder
(PDU decoder) to decode PDU (req/res message) to display the contents in the
GUI? I think, we can reuse the existing UI.
we have all the code to encode/decode PDU. The idea is to rewrite the Proxy as an eclipse plugin, and to integrate ot into Studio, not to define a Swing UI. This might be a bit more complex, but more powerful and useful.

cordialement, regards,
Emmanuel Lécharny