rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Stable API and Non-recursive list-at-time


From: Anthony Toole
Subject: Re: [rdiff-backup-users] Stable API and Non-recursive list-at-time
Date: Tue, 22 Jun 2010 18:07:54 +0100

Hi Darren,

Are you aware that there is already a rdiff-backup FUSE plugin?

http://code.google.com/p/archfs/

Cheers,
Anthony

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]