Projects/Marble/TileDownload - Revision history

Tgridel at 22:07, 29 January 2010

2010-01-29T22:07:30Z

Tgridel at 22:41, 20 January 2010

2010-01-20T22:41:11Z

Jmho: /* Design considerations */ update, removed obsolete stuff

2010-01-12T20:10:52Z

‎Design considerations: update, removed obsolete stuff

Tampakrap at 19:35, 23 March 2009

2009-03-23T19:35:05Z

Tampakrap at 14:50, 18 March 2009

2009-03-18T14:50:29Z

Tampakrap at 14:31, 18 March 2009

2009-03-18T14:31:41Z

Tampakrap at 14:18, 18 March 2009

2009-03-18T14:18:43Z

Tampakrap: New page: === Design considerations === 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 "...

2009-03-18T13:04:44Z

New page: === Design considerations === 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 "...

New page

=== Design considerations ===

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.

@@ Line 26: / Line 26: @@
 HttpDownloadManagers, which in turn have their own PluginManager, StoragePolicy and DownloadQueueSets. This looks suboptimal and hard to evolve.
-=== Current Work ===
+- The many HttpDownloadManagers are
-- Work is ongoing to have only one PluginManager belonging in the {{class|MarbleModel|kdeedu|4.x}}, which others could use when needed, currently
- * {{class|LayerManager|kdeedu|4.x}},
- * {{class|HttpDownloadManager|kdeedu|4.x}},
- * {{class|PositionTracking|kdeedu|4.x}}
-So HttpDownloadManagers would need to use it.
-−
-- Many HttpDownloadManagers created "in the wild" for different purposes, like in
   * {{class|AbstractDataPluginModel|kdeedu|4.x}} (and so all *PluginModel which inherit...),
   * {{class|MarbleModel|kdeedu|4.x}},

@@ Line 9: / Line 9: @@
 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

@@ 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.
-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
 The TileLoader should be able to handle not only files, but also QByteArrays or whatever is delivered by the network plugin interface.

@@ Line 8: / Line 8: @@
 Separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.
 === Design proposal ===
 to be done

← Older revision		Revision as of 14:50, 18 March 2009
Line 8:		Line 8:

	Separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.		Separation between http download and tile providing since http download is needed for wikipedia (and perhaps other stuff) integration also.
		+
		+	=== Design proposal ===
		+
		+	to be done

← Older revision		Revision as of 14:31, 18 March 2009
Line 6:		Line 6:

	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.

← Older revision		Revision as of 14:18, 18 March 2009
Line 4:		Line 4:

	Connections to tile servers should use the "keep alive" feature. At the moment for every tile a new connection is created.		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.