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: Darren Hart
Subject: Re: [rdiff-backup-users] Stable API and Non-recursive list-at-time
Date: Tue, 22 Jun 2010 11:28:15 -0700

On Tue, Jun 22, 2010 at 10:07 AM, Anthony Toole <address@hidden> wrote:
> Hi Darren,
>
> Are you aware that there is already a rdiff-backup FUSE plugin?
>
> http://code.google.com/p/archfs/

I had no idea! This is excellent, I'll have a look and see how it
does. Thanks for the link - I'm glad I posted early ;-)

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



-- 
Darren Hart



reply via email to

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