summaryrefslogtreecommitdiff
path: root/Types/StoreRetrieve.hs
Commit message (Collapse)AuthorAge
* remove 163 lines of code without changing anything except importsGravatar Joey Hess2016-01-20
|
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* pushed checkPresent exception handling out of Remote implementationsGravatar Joey Hess2014-08-06
| | | | | | | | | | | | | | | | I tend to prefer moving toward explicit exception handling, not away from it, but in this case, I think there are good reasons to let checkPresent throw exceptions: 1. They can all be caught in one place (Remote.hasKey), and we know every possible exception is caught there now, which we didn't before. 2. It simplified the code of the Remotes. I think it makes sense for Remotes to be able to be implemented without needing to worry about catching exceptions inside them. (Mostly.) 3. Types.StoreRetrieve.Preparer can only work on things that return a Bool, which all the other relevant remote methods already did. I do not see a good way to generalize that type; my previous attempts failed miserably.
* better byteRetrieverGravatar Joey Hess2014-08-03
| | | | | | | | | | | | | | Make the byteRetriever be passed the callback that consumes the bytestring. This way, there's no worries about the lazy bytestring not all being read when the resource that's creating it is closed. Which in turn lets bup, ddar, and S3 each switch from using an unncessary fileRetriver to a byteRetriever. So, more efficient on chunks and encrypted files. The only remaining fileRetrievers are hook and external, which really do retrieve to files.
* specialize Preparer a bit, so resourcePrepare can be addedGravatar Joey Hess2014-08-02
| | | | | | | The forall a. in Preparer made resourcePrepare not seem to be usable, so I specialized a to Bool. Which works for both Preparer Storer and Preparer Retriever, but wouldn't let the Preparer be used for hasKey as it currently stands.
* optimise case of remote that retrieves FileContent, when chunks and ↵Gravatar Joey Hess2014-07-29
| | | | | | | | | | encryption are not being used No need to read whole FileContent only to write it back out to a file in this case. Can just rename! Yay. Also indidentially, fixed an attempt to open a file for write that was already opened for write, which caused a crash and deadlock.
* better type for RetrieverGravatar Joey Hess2014-07-29
| | | | | | | | Putting a callback in the Retriever type allows for the callback to remove the retrieved file when it's done with it. I did not really want to make Retriever be fixed to Annex Bool, but when I tried to use Annex a, I got into some type of type mess.
* allow Retriever action to update the progress meterGravatar Joey Hess2014-07-29
| | | | | | | | Needed for eg, Remote.External. Generally, any Retriever that stores content in a file is responsible for updating the meter, while ones that procude a lazy bytestring cannot update the meter, so are not asked to.
* lift types from IO to AnnexGravatar Joey Hess2014-07-29
| | | | | | | | | | | Some remotes like External need to run store and retrieve actions in Annex, not IO. In order to do that lift, I had to dive pretty deep into the utilities, making Utility.Gpg and Utility.Tmp be partly converted to using MonadIO, and Control.Monad.Catch for exception handling. There should be no behavior changes in this commit. This commit was sponsored by Michael Barabanov.
* add ContentSource type, for remotes that act on files rather than ByteStringsGravatar Joey Hess2014-07-29
Note that currently nothing cleans up a ContentSource's file, when eg, retrieving chunks.