Well let me say that I for one am looking for candidates that will stick around as part of the community well after GSOC is over. Although there are no such requirements, I'm personally not interested in people coming, writing code, then leaving the project. I know life can do that and there needs to be flexibility but we're hoping you'll be around as part of our family here.
With that said yes the load balancing proxy idea is involved and will take much more than 3 months to perfect. However it is challenging and fun to do - much better than a boring easy project. Also the beauty of this is that I assure you several people and companies will want to use this for not just ApacheDS but other LDAP servers which are proxied. The user base will be there to help you work out the kinks - and that's pretty sweet to get feedback from those using it in the feild.
So I would not be concerned about time frames and other things. Pick something you're going to like doing and attack it. Rip open your shirt and show us the 'S' underneath that people with passion have. Be brave, and willing to fail even. You learn more from failures and challenging situations than you do successes.
WRT the components that will be involved. Take a look around and tell us what you think will be needed/involved. This will help you understand the big picture. When you see the big picture yourself instead of someone telling you what it should look like, it has much more meaning to you. It's your big picture.
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?
RahulOn Wed, Mar 4, 2009 at 3:44 PM, Alex Karasulu <firstname.lastname@example.org> 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.
AlexOn Tue, Mar 3, 2009 at 5:50 PM, Emmanuel Lecharny <email@example.com> wrote:
Rahul SOA wrote:yep.
so that means it is not available in the current version of the Studio. IsIt was a Swing 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.
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.