Add a 'canceled' signal

Bug #1211528 reported by Barry Warsaw
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I think we need a 'canceled' signal that will inform the client when a 'cancel' request has been fulfilled. Without this, I think we have a bit of a race condition and/or ambiguity.

In normal usage, the client will request downloading for several files in parallel. The client only cares about all-or-nothing, i.e. all the files get downloaded successfully or none of them do. This semantic isn't the responsibility of d/l service, but right now we can't reliably implement it on top of the current API.

Let's say we request files A, B, and C. File A is missing or gets an error, and we'll see its Download object get an `error` signal. Now we want to cancel all outstanding downloads, since we don't care about them, so we cancel B and C. In the meantime though B actually completed, and we'll see its `finished` signal - we can just delete that file. But what about C? If it got successfully canceled, we won't know it until we timeout our wait loop so at best, it's wasteful. At worst, we'll never get the `finished` signal or the `error` signal and so we'll never know whether we need to clean up the destination file or not, or even when it's safe to do so.

A `canceled` signal would tell us that the cancel was processed, and that there's nothing to clean up.

Revision history for this message
Barry Warsaw (barry) wrote :

There was always a canceled signal, it just wasn't documented.

Changed in ubuntu-download-manager:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints