Return-Path: Delivered-To: apmail-incubator-directory-dev-archive@www.apache.org Received: (qmail 51707 invoked from network); 8 Feb 2005 04:30:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 8 Feb 2005 04:30:55 -0000 Received: (qmail 68118 invoked by uid 500); 8 Feb 2005 04:30:54 -0000 Delivered-To: apmail-incubator-directory-dev-archive@incubator.apache.org Received: (qmail 68006 invoked by uid 500); 8 Feb 2005 04:30:54 -0000 Mailing-List: contact directory-dev-help@incubator.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 directory-dev@incubator.apache.org Received: (qmail 67972 invoked by uid 99); 8 Feb 2005 04:30:54 -0000 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=FROM_ENDS_IN_NUMS,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of aok123@bellsouth.net designates 205.152.59.72 as permitted sender) Received: from imf24aec.mail.bellsouth.net (HELO imf24aec.mail.bellsouth.net) (205.152.59.72) by apache.org (qpsmtpd/0.28) with ESMTP; Mon, 07 Feb 2005 20:30:50 -0800 Received: from [172.16.1.7] ([65.80.200.112]) by imf24aec.mail.bellsouth.net (InterMail vM.5.01.06.11 201-253-122-130-111-20040605) with ESMTP id <20050208043048.EUFC2021.imf24aec.mail.bellsouth.net@[172.16.1.7]> for ; Mon, 7 Feb 2005 23:30:48 -0500 Message-ID: <42084078.4000204@bellsouth.net> Date: Mon, 07 Feb 2005 23:30:48 -0500 From: Alex Karasulu User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: Virtual Directory (or LDAP Proxy) References: <20050208035257.B14F213FE4@mail.vergenet.com> In-Reply-To: <20050208035257.B14F213FE4@mail.vergenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Adison Wongkar wrote: >Hi Alex, > > > >>Well a combination of approaches can be used. You can wrap backends >>around disparate data sources to access them in a standard mannar. >> >>I think you may need to do both but time will tell. With other LDAP >>servers you never had >>a choice: a backend was the only option. With ApacheDS you >>have an added >>degree of >>freedom that may allow you to do even more. >> >> >> > >We're thinking at least initially we would implement the virtual directory >component as a backend. Ie. implementing the >org.apache.ldap.server.BackingStore or >org.apache.ldap.server.ContextPartition 's methods >(add/delete/modify/search/lookup etc.). > > Hmmmm you could certainly do that but I recommend against this approach. It's probably the easiest thing to do for you though. However we would like to parameterize the virtual directory specification as part of view management. >The virtual directory component: >- has mapping configuration (in XML) >- has working join & cache db (in memory or persistent) >- currently has adapters to databases and directories (we call these our >data sources) >- can map & combine attributes from the data sources > >Feel free to let me know what you think of this. > > Is this related to the stuff yall are doing at http://openvd.org? >NB: I also like the interceptor chain piece of the architecture. Perhaps we >can do something like ACL rules mapping, instead of just DIT & attributes >mapping. > > Could you explain this? I'm interested. I suspect by ACL you are refering to Access Control Lists. One thing we can definately use is an authorization mechanism in the server. Please tell me more. Alex