Re: [rdiff-backup-users] The rdiff-backup poll!

[Ben Escoto]

>>>>> Chris Wilson <address@hidden>
>>>>> wrote the following on Wed, 21 Dec 2005 01:58:41 +0000 (GMT)
> Hi Dean,
> 
> > why wouldn't you just spawn the rdiff-backup program?  otherwise you'd 
> > be dependent on the internal apis remaining stable... which doesn't seem 
> > like a good choice for your gui or for rdiff-backup development...
> 
> Well, I'm assuming that sooner or later rdiff-backup will have some kind 
> of stable API that I can use. Also, the compiler (and python bytecode 
> interpreter) will check that I'm using the correct API and give me a 
> warning if not. Trying to parse the output of a process is a nightmare 
> that I really don't want to get involved with (again).

Yes, callbacks may be easier than parsing rdiff-backup output, but
right now rdiff-backup doesn't support callbacks, and doesn't really
have a stable API.  Aside from the callback issue, I don't see the API
being much friendlier than spawning an rdiff-backup process.

Oh, as for learning python, I thought the tutorial and the FAQ list
were good.  Nowadays there are books on python though, so you may want
to look at one of them.

> > progress meters kind of depend on knowing how much there is to be
> > done, and rdiff-backup doesn't know that initially at
> > least... because it starts transferring data even before it has
> > scanned all the inodes needing backup.
> 
> Well, I guess I would have to change that :-)

I actually consider this a feature.  Since rdiff-backup only makes one
pass, it saves time making an extra pass through the directory tree.
Also, it doesn't need to fit the entire directory list in memory at
the same time (this is a common complaint against rsync).  Finally, it
doesn't need to worry about the various ways that the first pass can
differ from the second pass if the directory is changed.

You could have your program make a preliminary pass just to count the
number of files in the source directory, but I don't think
rdiff-backup needs to do this as a matter of course.


-- 
Ben Escoto

pgpGHKtQ_68e7.pgp
Description: PGP signature