jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Kennedy <da...@us.ibm.com>
Subject Re: Client/Server question
Date Wed, 31 May 2006 13:06:37 GMT
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" <ntoper@gmail.com> 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
> >
> >
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message