Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 49449 invoked from network); 31 May 2006 14:42:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 May 2006 14:42:46 -0000 Received: (qmail 30047 invoked by uid 500); 31 May 2006 14:42:45 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 30018 invoked by uid 500); 31 May 2006 14:42:44 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 30009 invoked by uid 99); 31 May 2006 14:42:44 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 07:42:44 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of ntoper@gmail.com designates 66.249.92.172 as permitted sender) Received: from [66.249.92.172] (HELO ug-out-1314.google.com) (66.249.92.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 May 2006 07:42:42 -0700 Received: by ug-out-1314.google.com with SMTP id a2so745995ugf for ; Wed, 31 May 2006 07:42:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=EF2Gm9SmysUPGRCf9b/A47MlxqQuB5S6zJFmg8rT3OTS7Y9rjMnPiiU81uVUIDAGQRPY75bAr0PSbqB0tYAUntWJaM6cQbBel7R4vrfMh6m3rtYTkRWHCyshtqLJ9x7gcyACAOmEIowVy5lFm8jSd4unm9KjpCq4f2R+q1qax8c= Received: by 10.78.51.16 with SMTP id y16mr3828huy; Wed, 31 May 2006 07:42:21 -0700 (PDT) Received: by 10.78.75.1 with HTTP; Wed, 31 May 2006 07:42:21 -0700 (PDT) Message-ID: Date: Wed, 31 May 2006 16:42:21 +0200 From: "Nicolas Toper" To: dev@jackrabbit.apache.org Subject: Re: Client/Server question In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5749_28740942.1149086541176" References: X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_5749_28740942.1149086541176 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Actually, Jukka and I decided to add the hotbackup fonctionnality in a next step. I will design the tool so this can be added easily later on. We want to create a tool "battle tested" and we fear adding a proxyPM might spread our effort and add too much testing cases for a first step (with probable appearances of transient and intermittent bugs). Please keep in mind, it is the first time, I am working with JackRabbit. See past Jukka mail: "This is something that we should look at later on. Modifying the internal persistence data path is quite risky in terms of possible new bugs and regressions so I'd rather not extend the scope of the SoC project to cover that. I'd be happy with just a global write lock that guarantees data consistency in the repository. For the SoC project I'd even be OK with a tool that simply relies on the administrator to enforce a no-write policy during backup. It's still better than we have now and we can extend and improve the solution later on." I will probably add hotbackup on one form or another after the Google SoC. BR, Nicolas my blog! http://www.deviant-abstraction.net !! On 5/31/06, David Kennedy < davek@us.ibm.com> wrote: > > What happened to the idea of backing up to a PesistenceManager and > restoing from one as well? As long as you add an interface and the > PersistenceManager implements the backup/restore interface, it's still > feasible, but was there a problem with this strategy? > > David > > "Nicolas Toper" wrote on 05/31/2006 08:51:31 AM: > > > Hi Felix, > > > > You are right on both points. I will do as you suggest. > > > > Thanks for your input. > > > > Best Regards > > Nico > > my blog! http://www.deviant-abstraction.net !! > > > > On 5/31/06, Felix Meschberger < fmeschbe@gmail.com> wrote: > > > > > > Hi Nicolas, > > > > > > I agree to include these methods on the repository layer. But thinking > > > > about the extent - rather than the intrincacies of handling concurrent > > > > modifications while backing up - I would have some remarks: > > > > > > (1) I would modify the signature to take InputStream and OutputStream > > > objects, resp. This provides for more flexibility in terms of source > > > and destination of the backup data. > > > > > > (2) Initially you mentioned a configuration file for the > > > backup/restore procedures. I suggest you define configuration classes > > > (interfaces), which can load/store themselves to and from streams > > > (yes, I do not like being locked into File instances :-) and to add > > > instances of the toplevel configuration (e.g. BackupConfiguration) as > > > a parameter to the backup/restore methods. > > > > > > These two changes would greatly improve the flexibility using the API > > > from within an application as opposed to from the command line. Also > > > testing would be greatly simplified, I suppose. > > > > > > Regards > > > Felix > > > > > > > > > > > ------=_Part_5749_28740942.1149086541176--