I'm currently working on the early stages of a fuse filesystem for rdiff-backup repositories. As I look through the rdiff-backup code I noticed that it is written around the command line interface (unsurprisingly). As I would like to use the rdiff-backup python packages directly, rather than forking a subprocess each time the fuse fs needs data, I wanted to get the developers' thoughts on the API of rdiff-backup. Are the rdiff-backup packages used by rdiff-backup's Main.py likely to remain more or less stable, or should I expect a lot of churn in how they are implemented?
While tinkering with generating listings (for 'ls') I found it would be a lot more efficient to be able to do a non-recursive restore.ListAtTime(). Specifically in MirrorStruct.get_rorp_iter_from_rf(). For example something like: def get_rorp_iter_from_rt(self, rf, recurse=True): would do the trick and requires no other changes to rdiff-backup. Perhaps the recurse option should be available higher up the stack as well, perhaps in restore.ListAtTime() itself, but the idea is the same. Would the developers be amenable to such a change? I'm sure I'll run into several more similar sorts of tweaks that would make the rdiff-backup packages more usable as a general purpose rdiff-backup repository access library, and I wanted to get a feel for how likely it will be for such changes to make it into rdiff-backup proper. Thanks, -- Darren Hart _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
