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

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

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


From: Darren Hart
Subject: [rdiff-backup-users] Stable API and Non-recursive list-at-time
Date: Tue, 22 Jun 2010 08:20:04 -0700

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]