Marble/TileDownload: Difference between revisions
m (Frinring moved page Projects/Marble/TileDownload to Marble/TileDownload) |
m (9 revisions imported: Import from techbase...) |
(No difference)
|
Latest revision as of 16:40, 25 October 2016
Design considerations, ideas, thoughts, nothing final
Perhaps create an (abstract) interface / abstract class TileProvider? Not sure, if there is an use case.
Perhaps separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.
What about redirects? in general it seems to be a good idea to support them, but do we also need the ability to forbid redirects of inform the user?
The TileLoader should be able to handle not only files, but also QByteArrays or whatever is delivered by the network plugin interface.
Documentation of existing code
Here are drop notes of understanding how downloading http stuff happens:
HttpDownloadManager is the entry point if you want to download http things.
This class handles download jobs by first creating a simple HttpJob, and providing it to one of the DownloadQueueSet classes which can behave according to various DownloadPolicyKey.
A StoragePolicy belongs to the HttpDownloadManager to handle downloaded files properly.
It also relies on the PluginManager to provide a NetworkPlugin which implements the createJob
In the current imlementation (trunk just after 4.4 branching), there are many HttpDownloadManagers, which in turn have their own PluginManager, StoragePolicy and DownloadQueueSets. This looks suboptimal and hard to evolve.
- The many HttpDownloadManagers are
* AbstractDataPluginModel (and so all *PluginModel which inherit...), * MarbleModel, * TwitterPlugin
Maybe one would be enough, given the DownloadQueues and StoragePolicies framework...
Design proposal
to be done