I believe this is really good start (thanks, @lebauce), but it would require more work on downloading part: it is not great that downloading happens while mirror update call is running. Probably there should be some separate API to control download progress/status.

I would move this to 0.10 so that 0.9 would happen sooner or later.

Concerning the download progress/status challenge:
I am working on an API which allows queuing of tasks and each task can update its own status/progress. The idea is all API calls which need a write lock will be queued into this queue and processed one by one. A separate API call can then be made to check the progress of a task.

An experimental and unfinished implementation you can find here https://github.com/sliverc/aptly/tree/queuing_api

Open tasks I am currently working on:

• Writers on API should not block out readers (rewriting of locking needed)
• Rewriting of api PUT, DELETE, POST calls to use queue

This is an idea on how to approach the issue of long API calls which would make it possible to implement this mirror api PR more easily.

I am quite eager for a mirrors api, is this generally safe to use? Should updating a mirror via this API be avoided or is it simply a sub-optimal interface to the long running process?

I didn't check the code, I think the biggest issue mirror update, as it might take considerable amount of time, and blocking in API call doesn't make sense.

Closing in favor of #573