From dev-return-29289-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Thu Mar 05 16:24:40 2009 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 99869 invoked from network); 5 Mar 2009 16:24:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Mar 2009 16:24:40 -0000 Received: (qmail 4232 invoked by uid 500); 5 Mar 2009 16:24:40 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 4037 invoked by uid 500); 5 Mar 2009 16:24:40 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 4028 invoked by uid 99); 5 Mar 2009 16:24:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Mar 2009 08:24:40 -0800 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.217.171 as permitted sender) Received: from [209.85.217.171] (HELO mail-gx0-f171.google.com) (209.85.217.171) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Mar 2009 16:24:30 +0000 Received: by gxk19 with SMTP id 19so18828gxk.3 for ; Thu, 05 Mar 2009 08:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=8sMq4gWIVOl+rRWvjiuhlGWD5bCSpxd99J4AKJVAckU=; b=wZ3ZKrsQWdIDqvHeEoBcNh4tPMJQrAAz8SIMgnsmcMqmQFL4HYSAYbOyYhWPPnWuEp qb5cMeRbU/D0M5C3KgaHJ8HMHWn1dYgbDqPZRj+Lp4rLwEqxFm0ZTAYGr1rwZATL7mIs 4gfzegp79wb1KiXz6QLsPt8H46CTHzu73CXFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=KBKSW4jm9ct8fyKnWMUzwwjv3Okh5JTp8WkG+ZJ5AUkBuxig+VoeYYqM0gb/3eArDi 5CcHOq9VAKcX16MNW9xPhjAY7g5Izu4fDtjCcs2TSMMfM1bCNJRGTQ7H0yvUV+yf3xc7 /2xaKa5l5uOoNqP2TtMtdSDil0LCz5+Uo3LKQ= MIME-Version: 1.0 Received: by 10.231.15.74 with SMTP id j10mr376506iba.30.1236270248643; Thu, 05 Mar 2009 08:24:08 -0800 (PST) In-Reply-To: References: <49AD16F7.2030101@nextury.com> <49ADA22D.90206@nextury.com> <49ADB42E.1090502@nextury.com> Date: Thu, 5 Mar 2009 11:24:08 -0500 Message-ID: Subject: Re: want to contribute in the project From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=00221532cba00450360464619969 X-Virus-Checked: Checked by ClamAV on apache.org --00221532cba00450360464619969 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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. Regards, Alex On Wed, Mar 4, 2009 at 5:41 PM, rahul.soa wrote: > 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 fo= r > me to evaluate about the volume of work involved in this LDAP proxy proje= ct > 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, > Rahul > > > > > On Wed, Mar 4, 2009 at 3:44 PM, Alex Karasulu 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 bala= ncer >> 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 replic= as >> 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= =3Dra*) >> 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 tim= e >> 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. >> >> Thanks, >> Alex >> >> >> On Tue, Mar 3, 2009 at 5:50 PM, Emmanuel Lecharny = wrote: >> >>> Rahul SOA wrote: >>> >>>> It was a Swing ui >>>>>> >>>>> so that means it is not available in the current version of the >>>> Studio. Is >>>> >>>> >>>>> it? >>>>> >>>>> >>>> yep. >>> >>>> 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 content= s >>>>>> 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 def= ine a >>> Swing UI. This might be a bit more complex, but more powerful and usefu= l. >>> >>> >>> >>> -- >>> -- >>> cordialement, regards, >>> Emmanuel L=E9charny >>> www.iktek.com >>> directory.apache.org >>> >>> >>> >> > --00221532cba00450360464619969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well let me say that I for one am looking for candidates that will stick ar= ound as part of the community well after GSOC is over. Although there are n= o such requirements, I'm personally not interested in people coming, wr= iting code, then leaving the project.=A0 I know life can do that and there = needs to be flexibility but we're hoping you'll be around as part o= f our family here.

With that said yes the load balancing proxy idea is involved and will t= ake much more than 3 months to perfect. However it is challenging and fun t= o do - much better than a boring easy project. Also the beauty of this is t= hat I assure you several people and companies will want to use this for not= just ApacheDS but other LDAP servers which are proxied.=A0 The user base w= ill be there to help you work out the kinks - and that's pretty sweet t= o get feedback from those using it in the feild.

So I would not be concerned about time frames and other things. Pick so= mething you're going to like doing and attack it. Rip open your shirt a= nd show us the 'S' underneath that people with passion have. Be bra= ve, 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 u= s what you think will be needed/involved.=A0 This will help you understand = the big picture.=A0 When you see the big picture yourself instead of someon= e telling you what it should look like, it has much more meaning to you.=A0= It's your big picture.

Regards,
Alex

On Wed, Mar 4, 2009 = at 5:41 PM, rahul.soa <rahul.soa@googlemail.com> wrote:
Hello Alex/Emmanuel,

Thanks for your suggestions.

With all th= is discussion and information provided by you and some of the pointers sear= ched on internet, I am interested in the proxy project and I think with the= smart load balancer (more interested in this), failover mechanism, securit= y features can make LDAP Proxy more robust.=A0 btw, is developing a load bl= aancer 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 pro= ject 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 de= fined based on the existing functionality for Proxy)?

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

Thanks = again.

Best Regards,
Rahul




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

=A0 o New LDAP Client API based on entry API
=A0=A0=A0=A0=A0 - = new client implementation to replace using JNDI
=A0 o ApacheDS command c= onsole using new mina SSH server
=A0=A0=A0=A0=A0 - you ssh into ApacheDS to issue commands for managing it=A0 o Finish off object/class mapping for LDAP
=A0=A0=A0=A0=A0 - 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 ot= her opportunities with an LDAP proxy. Namely as a LDAP smart load balancer = or switch.=A0 Not many load balancers out there consider application layer = (7) specifics, even less specifically are aware of LDAP issues when it come= s to load balancing.=A0 The proxy can help with that and can be a stand alo= ne service.

You can do so much here:

=A0 o distribute client connections bas= ed on a namingContext across replicas serving that context
=A0 o distrib= ute search requests based last similar request to take advantage of already= populated cache - for example if I search for (uid=3Dra*) on replica A wit= h client 1, then it makes sense to route the same search from client 2 to r= eplica A if the same request is issued within some time threshold.=A0 This = way the cache in replica A containing for the index on uid can be used to p= erform 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.=A0 Might be a fun pr= oject that would produce something very useful in production.

Thanks= ,
Alex


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

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 th= e
GUI? I think, we can reuse the existing UI.
=A0 =A0 =A0
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 Swi= ng UI. This might be a bit more complex, but more powerful and useful.



--
--
cordialement, regards,
Emmanuel L=E9charny
www.iktek.com
directory.apache.= org





--00221532cba00450360464619969--