To avoid conflict with different liftIO from MonadIO (in some version of
yesod not the one I have here), and because it's generally clearer, since
this module has both Wai and Yesod stuff, to qualify them both.
This makes the buttons in the UI a little clearer. I'd prefer to enable the
barberpole animation for running transfers, but that is jerky looking due
to the way the dashboard is updated.
I had an intuition that throwTo might be blocking because an exception was
caught and the exception handler was running. This seems to be the case,
and is avoided by using try. However, I can't really find anywhere in
throwTo's documentation that justifies this behavior.
When multiple downloads of a key are queued, it starts the first, but leaves the
other downloads in the queue. This ensures that we don't lose a queued
download if the one that got started failed.
Drives that are not mounted still have Remotes, and it makes sense to scan
them along with all the other remotes on startup, so we end up with queued
transfers for them, that will be used when they get mounted.
Seems cabal defaults to trying to satisfy both flags, which cannot works,
and does not fall back to only selecting one, as hoped. While users could
manually specify flags, I don't want to require that to build, so let's
just require the newer yesod version when building with cabal.
Run code that pops off the next queued transfer and adds it to the active
transfer map within an allocated transfer slot, rather than before
allocating a slot. Fixes the transfers display, which had been displaying
the next transfer as a running transfer, while the previous transfer was
still running.
