Re: [Duplicity-talk] Proposal for backgrounded concurrent I/O with new retry support

[Kenneth Loafman]

Peter Schuller wrote:
> Hello,
> 
> I have been looking through the code some, with an eye towards two features:
> 
>   (1) backgrounding all backend I/O, and allowing for concurrency

As long as the order is maintained, then there should be no problem, but
I imagine most people will be happy with a concurrency of 2 or so.  My
observation is that the build and IO take about the same amount of time
on a relatively fast network, so you could double your speed there quite
easily.  On a slow network, you could at least guarantee that there was
no dead time other than what the network demands.

>   (2) the ability to pause retries until an operator indicates the backend 
> should resume retrying, as has been previously discussed on the list

For those that run interactively, this would be a good thing.  The only
requirement I would impose on any implementation is that it must be able
to run under cron, or similar, without human intervention.

That said, a cron job that somehow interactively prompts the operator
for help may be a good thing, if it can be done without using the system
console since some machines have none.  Your --retry-failure-* options
may be able to feed a monitoring task, in which case, multiple
duplicity's could be run at the same time to different directories.

All very good ideas and plans!  Do you need a branch on CVS so you can
work on a separate tree, then merge later?  Or will it be just one big
release sometime down the road?

...Ken

signature.asc
Description: OpenPGP digital signature