Jump to content

Marble/TileDownload: Difference between revisions

From KDE Community Wiki
No edit summary
Jmho (talk | contribs)
Design considerations: update, removed obsolete stuff
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.
 
Connections to tile servers should use the "keep alive" feature. At the moment for every tile a new connection is created.


Perhaps create an (abstract) interface / abstract class TileProvider? Not sure, if there is an use case.
Perhaps create an (abstract) interface / abstract class TileProvider? Not sure, if there is an use case.


Separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.
Perhaps separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.
 
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.


It should be possible to set a storage policy for the network plugin, so downloaded content could be saved in files for example.
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.
The TileLoader should be able to handle not only files, but also QByteArrays or whatever is delivered by the network plugin interface.

Revision as of 20:10, 12 January 2010

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.

Design proposal

to be done