From dev-return-34137-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sat Jun 05 08:43:58 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 80646 invoked from network); 5 Jun 2010 08:43:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 5 Jun 2010 08:43:58 -0000 Received: (qmail 66160 invoked by uid 500); 5 Jun 2010 08:43:57 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 66049 invoked by uid 500); 5 Jun 2010 08:43:57 -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 66042 invoked by uid 99); 5 Jun 2010 08:43:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Jun 2010 08:43:56 +0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=AWL,FREEMAIL_FROM,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 74.125.82.50 as permitted sender) Received: from [74.125.82.50] (HELO mail-ww0-f50.google.com) (74.125.82.50) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 05 Jun 2010 08:43:50 +0000 Received: by wwb17 with SMTP id 17so1746148wwb.37 for ; Sat, 05 Jun 2010 01:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bZmjwSR2odEWF/ZWws+IYQUxGpjBhGwvftjJPYJCpO8=; b=e5Rc/s3DtirWb+jo68EeG7yjGh+gT/aKSi3Q6SuXMnu7kYp79r2okBZUjenA2o4YAX 48+IBJagyol2lglED4NNOo8y+1EShl137RLora7l9u+AnZUxBqP00QHZnShdnC0l59Wr UFGIikMTlOE9VpwUIcSzqzGnQdGgF41PjJCTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KNXl4KXxSA8mIs6ti51GO0N0USWwS03zax/aLuTahMauYcFf/24qKHCf1AxdZssAcB IBC4pXLZpXCSgxqqbKCS6ZH3oY/qqLQiBeXLxZMc1tn9C1fYfnMWkHGNASxycuE9ogoT bpKYrLd8GNaekaXQFl8l+/UCtzYMAZydSOKNA= Received: by 10.227.141.135 with SMTP id m7mr11692569wbu.205.1275727408855; Sat, 05 Jun 2010 01:43:28 -0700 (PDT) Received: from emmanuel-lecharnys-MacBook-Pro.local ([78.192.106.184]) by mx.google.com with ESMTPS id n31sm17431211wba.21.2010.06.05.01.43.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Jun 2010 01:43:27 -0700 (PDT) Message-ID: <4C0A0E54.4000909@gmail.com> Date: Sat, 05 Jun 2010 10:44:04 +0200 From: Emmanuel Lecharny Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: What should we do with apacheds-server-tools ? References: <4C0910EE.7030203@gmail.com> <4C0A0CF9.9030306@apache.org> In-Reply-To: <4C0A0CF9.9030306@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 6/5/10 10:38 AM, Stefan Seelmann wrote: > Emmanuel Lecharny wrote: > >> Hi guys, >> >> this module is broken since, pfeww, september 11 2008 (what a >> coincidence ! Bad things always happen on 11/09...) >> >> The question is : should we keep going and fix this module or should we >> move it to the deceased projects ? A thrd option would be to make this >> module a separate project we can release separately from ADS 2.0. >> >> Wdyt is the best ? >> > I think we need to provide some CLI tools for administrating the server. > At least we need a tool to re-build the index and to backup and restore > the data in LDIF format including all operational attributes. Similar to > OpenLDAP's slapindex, slapcat, and slapadd. > > IMO the problem with the current tools is that they are dedicated to > JDBM partitions and directly works on the *.db files. > > Instead I think we should build those tools into the partition > implementation. We could extend the Partition interface with some new > methods: > void buildIndex(); > void backup( File/URL toFile ); > void restore( File/URL fromFile ); > and define extended operations to trigger those methods. The extended > operations could be invoked from within Studio or from a new CLI tool. > +1. This is most certainly what we need. > Of course, the problem is (as always) time. > Ahhh... You can't buy time. You can't sell it either ;) -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com