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 < [EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 > > > > > >
