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 > > > > > >
