If Storage::syncSaves() is called when sync is running, another sync
would be automatically scheduled in the end of the current one.
That could be helpful when we want to specify that we changed something
during sync (created new save slot, for example).
It's shown by SaveLoadChooserDialog when files are downloaded and some
save slots are locked. One can hide that dialog to interact with
non-locked slots or cancel saves sync completely. Dialog's label shows
current sync progress.
Dialog automatically hides itself when all files are downloaded.
WARNING: right now that results in a crash!
It now keeps track of how many Requests are running.
To achieve that, we had to pass a callback to ConnectionManager, so each
Request has a callback paired with it. If that's one of Storage's
Requests, it has a callback, which would decrease a counter. When
Storage adds a Request, it also increases a counter and passes that
callback. Callback is called by ConnMan when Request is deleted.
isWorking() returns true if there is at least one Request running.
DownloadRequest and FolderDownloadRequest are using other Storage's
methods. Thus, download() and downloadFolder() could be implemented in
base Storage class.
As it uses SavesSyncRequest and this request is using Storage's
upload(), download() and listDirectory(), there is no need to make
storage-dependent version of that request and so method could be
implemented in base Storage.
With ConnectionManager singleton one can start their Requests without
creating Storage instance. Moreover, Storage instance should contain
cloud API, not Requests-related handling and timer starting methods.
Thus, these methods were moved into ConnectionManager itself.
NetworkReadStream actually saves whole response in the memory now.
There is a pause mechanism in libcurl, but if libcurl is requesting
something compressed, it would have to uncompress data as it goes even
if we paused the request. Even though our own stream won't be notified
about this data when when "pause" the request, libcurl's own buffer
wound be expanding.
CurlRequest uses own multi_handle, in which it creates an easy_handle to
make a request.
Every time `handle()` is called it checks whether request is complete
and, if it is, stops.
This commit introduces Common::CloudManager, which can be accessed from
OSystem.
The backend for this manager is Cloud::Manager (defined in
backends/cloud/manager.h). It should load all users storages from
configs and provide access to current Storage instance. For now it just
creates a new one.
Cloud::Storage (backends/cloud/storage.h) provides an API to interact
with cloud storage, for example, create new directory or sync files.
Right now it's not ready and has only two dummy methods: listDirectory()
and syncSaves().
There is Cloud::Dropbox::DropboxStorage backend
(backends/cloud/dropbox/dropboxstorage.h) for Cloud::Storage. Right now
it implements both listDirectory() and syncSaves() with starting timer
task and handling it by printing out some JSON examples.
