From dev-return-30867-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sun Aug 02 19:17:13 2009 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 26843 invoked from network); 2 Aug 2009 19:17:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Aug 2009 19:17:13 -0000 Received: (qmail 5498 invoked by uid 500); 2 Aug 2009 19:17:18 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 5399 invoked by uid 500); 2 Aug 2009 19:17:18 -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 5391 invoked by uid 99); 2 Aug 2009 19:17:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Aug 2009 19:17:18 +0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=SPF_PASS,SUBJECT_FUZZY_TION X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates 209.85.219.213 as permitted sender) Received: from [209.85.219.213] (HELO mail-ew0-f213.google.com) (209.85.219.213) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 02 Aug 2009 19:17:07 +0000 Received: by ewy9 with SMTP id 9so2733210ewy.25 for ; Sun, 02 Aug 2009 12:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fXULKXuD4KwfSnywgZ2EFpU5rGIYs5/zEccpXacTGcM=; b=mHkaU8Cgr5QatFPzUuxsCiKzhL5toHjtT/7zJr5cChSFHMpctWlwnkcc/QobNtFTXZ ZqxFqyNsHwdnkICcVZ5shz/E2TU3byMttJqJms/tmqrflo0WVWpwd0DNHNh+HaoEBIDE mbIrSVvHFvkvbc8jQEREa1C5FCpNix9/NIW04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vbgGr8KTGywOK2zC3YGAGdewLpLDsvVjmVIGe4mUUtaswOk1qWBg2fxWcY0Psoga1R WtT2Ih9yUB+EbV8wqwn6PntzwCxOvleJQAuvQEkdbHmoQwx9spdN1cLsqHKeLd+cRHp8 4zBLybJ0sAcPQsjbBWWEfgTOfQCbyfMUcipN4= Received: by 10.211.180.19 with SMTP id h19mr4012885ebp.35.1249240606746; Sun, 02 Aug 2009 12:16:46 -0700 (PDT) Received: from ?192.168.0.201? (lns-bzn-49f-62-147-228-243.adsl.proxad.net [62.147.228.243]) by mx.google.com with ESMTPS id 5sm10086304eyh.36.2009.08.02.12.16.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Aug 2009 12:16:45 -0700 (PDT) Sender: Emmanuel Lecharny Message-ID: <4A75E5FD.7020504@nextury.com> Date: Sun, 02 Aug 2009 21:16:13 +0200 From: Emmanuel Lecharny User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [ApacheDS] do we need a special partition for CiDIT? References: <4A75A748.3050800@gmail.com> In-Reply-To: <4A75A748.3050800@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Kiran Ayyagari wrote: > hello guys, > > As a second step in getting the CiDIT [1] am currently > implementing a new partition which uses > LDIF files as backend, however as I go deeper in > implementation(atm the partition supports add operation) > I asked a couple of questions to myself which I would like to > share and seek opinion on > > 1. Instead of creating a whole new partition impl for storing > CiDIT can we use the existing (and well tested) > JDBM partition? Well, at first sight, I don't think it's a good idea. The initial target was to allow an admin to manipulate the conf without having to use a tool to change the config. Being able to modify the conf with vi/emacs/notepad is always a good thing compared to having a broken conf in an opac file. But ... > > The JDBM based partition stores data in binary format but in > order to make the configuration editable using > a simple text editor I propose the following steps > > a. After initial startup of server the default configuration > will be dumped to the file system as a single > LDIF file or as a set of directories and LDIF files( > mimicking the DIT structure) What if the JDBM file is broken ? > > b. A watchdog thread will keep listening on this file(s) for > changes > > i. any change of type update/delete done to the content > of file(s) will be reflected in > the CiDIT accordingly, but > > ii. If the file itself gets deleted we *don't* delete the > configuration data in DIT but simply dump > that data again to file system. To delete the > configuration data completely the corresponding > partition needs to be physically removed from the > disk in which case the system restores the > default configuration during the next startup > > c. similarly this file(s) gets updated if the configuration > data DIT gets updated > > > thanks for your time and I appreciate your comments :) Ok, I see where you want to go : basically, guarantee that the config can be read as we know that if it's JDBM packed, the partition will work. I would say that as a first step, to debug the config itself (ie, to check that all the parameters are OK), we can do that. But at the end, I really think we must go for a text based config. > > P.S:- Though implementing a partition is not difficult it is > certainly not trivial, am thinking in terms of > maintaining code and the amount of configuration required for > each new partition impl to be used in server > and also considering the time we have to implement replication > support in 2.0 IMO, writing a new partition bascked by ldif files should not really take much more than 2 weeks. But as we really need to have some config element for the replication subsystem, and if going with JDBM backed config will help, I would say : go for it. Thanks ! > > > [1] > http://cwiki.apache.org/confluence/display/DIRxSRVx20/ADS+2.0+configuration > > > Kiran Ayyagari > -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org