Difference between revisions of "Projects/Marble/TileDownload"

Jump to: navigation, search
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
=== Design considerations ===
+
=== Design considerations, ideas, thoughts, nothing final ===
  
Downloading of tiles should be in separate threads so that each connection to a tile server has its own thread.
+
Perhaps create an (abstract) interface / abstract class TileProvider? Not sure, if there is an use case.
  
Connections to tile servers should use the "keep alive" feature. At the moment for every tile a new connection is created.
+
Perhaps separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.
  
Perhaps create an (abstract) interface / abstract class TileProvider? Not sure, if there is an use case.
+
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?
  
Separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.
+
The TileLoader should be able to handle not only files, but also QByteArrays or whatever is delivered by the network plugin interface.
  
The interface needs to support asynchronous calls because inside the network plugin we want to have a threaded implementation.
 
  
The network plugin should be able to handle redirects but it should also be possible to forbid redirects or to inform about redirects.
+
=== Documentation of existing code ===
  
It should be possible to set a storage policy for the network plugin, so downloaded content could be saved in files for example.
+
Here are drop notes of understanding how downloading http stuff happens:
  
The TileLoader should be able to handle not only files, but also QByteArrays or whatever is delivered by the network plugin interface.
+
{{class|HttpDownloadManager|kdeedu|4.x}} is the entry point if you want to download http things.
 +
 
 +
This class handles download jobs by first creating a simple {{class|HttpJob|kdeedu|4.x}}, and providing it to one of the {{class|DownloadQueueSet|kdeedu|4.x}} classes which can behave according to various {{class|DownloadPolicyKey|kdeedu|4.x}}.
 +
 
 +
A {{class|StoragePolicy|kdeedu|4.x}} belongs to the HttpDownloadManager to handle downloaded files properly.
 +
 
 +
It also relies on the {{class|PluginManager|kdeedu|4.x}} to provide a {{class|NetworkPlugin|kdeedu|4.x}} 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
 +
* {{class|AbstractDataPluginModel|kdeedu|4.x}} (and so all *PluginModel which inherit...),
 +
* {{class|MarbleModel|kdeedu|4.x}},
 +
* {{class|TwitterPlugin|kdeedu|4.x}}
 +
Maybe one would be enough, given the DownloadQueues and StoragePolicies framework...
  
 
=== Design proposal ===
 
=== Design proposal ===
  
 
to be done
 
to be done

Latest revision as of 23:07, 29 January 2010

[edit] 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.


[edit] 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...

[edit] Design proposal

to be done


This page was last modified on 29 January 2010, at 23:07. This page has been accessed 3,649 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal