ConnectionManager used to poll Cloud requests every second, while curl
requests were polled every 1/20th of a second. If curl request was over
at, say, frame #21, corresponding Cloud request would've only work with
that at frame #40 (950 ms later), which was making everything
cloud-related slower than it could be. This commit fixes it by making
Cloud polling period the same as curl polling period, and additionally
raises FPS to 25.
This fixes tons of warnings with clang from a recent xcode version on
macOS (and possibly other systems) complaining that an instantiation
of _singleton is required but no definition is available.
The cloud manager registers itself as an event source as a mean to be polled
periodically by the GUI or engine code. The periodical polling is used to
update the OSD icon indicating background sync activity.
Also move the cloud icon from ConnectionManager to CloudManager,
allowing to decouple icon handling from network connections updates.
It now keeps newly added Requests in separate array, so iterators don't
break when one adds a Request while ConnMan iterates its array.
The array is also shielded with mutex.
CloudIcon is now a Request which is automatically added once first
Request is added to ConnMan. When icon decides it should disappear, it
gets FINISHED, so ConnMan would switch off the timer if it was the last
Request.
I didn't like how FINISHED Requests were waiting until the next
interateRequests() call to be removed when we could easily remove those
after they changed their state in their handle().
To achieve smoother animation, ConnectionManager's timer now is 20 times
more frequent.
I'm encountering some strange libcurl.dll segfault problem when I close
the application while some Requests are active. It's not
CloudIcon-related, so it's more likely related to this 20 FPS timer.
This problem shows up only in Visual Studio for me.
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.
ConnectionManager now storages Request * (not generates ids for it),
Requests have control on their RequestState, RequestIdPair is now called
Response and storages Request * with some response together.
All related classes are changed to use it in more clean and
understandable way.
Request, RequestState and Response are carefully commented/documented.
OneDriveTokenRefresher is a CurlJsonRequest replacement for
OneDriveStorage methods. It behaves very similarly, but checks received
JSON before passing it to user. If it contains "error" key, it attempts
to refresh the token through OneDriveStorage, and then restarts the
original request, so user won't notice that there ever was an error.
It reads the passed NetworkReadStream and prints its contents onto
console (for now). It would be writing contents into file.
To simplify work with raw NetworkReadStream there is a new CurlRequest.
It basically does nothing, but as ConnMan handles transfers only if
there is an active Request, you need some Request to get
NetworkReadStream working. Thus, there is a CurlRequest, which is active
until NetworkReadStream is completely read. CurlRequest also has useful
addHeader() and addPostField() methods in order to customize the request
easily. Use execute() method to get its NetworkReadStream.
DropboxStorage implements streamFile() and download() API methods. As
DownloadRequest is incomplete, it is not actually downloading a file,
though.
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.
This commit adds:
* ConfMan's new "cloud" domain;
* CloudManager's init() method, where it loads keys from "cloud" configs
domain;
* CurlJsonRequest's addHeader() and addPostField() methods;
* temporary Storage's printInfo() method;
* DropboxStorage's implementation of printInfo(), which is using access
token and user id;
* DropboxStorage's loadFromConfig() static method to load access token
and user id from configs and create a Storage instance with those;
* temporary DropboxStorage's authThroughConsole() static method, which
guides user through auth process from the console.
So, in CloudManager's init() implementation ScummVM checks that there is
"current_storage_type" key in "cloud" domain of configs, and loads
corresponding storage if there is such key.
If there is no such key, ScummVM offers user to auth with Dropbox.
That's done through console, and thus it's temporary (it also requires
restarting ScummVM twice and manually editing config.ini file).
Now we can do REST API request by creating CurlJsonRequest and waiting
for it to call our callback. Passed pointer is Common::JSONValue.
This commit also does some minor variable renaming fixes.
Now it is based on MemoryReadWriteStream, which is introduced by this
commit. This stream is using ring buffer and is dynamically increasing
its size when necessary.
