Re: NetworkMapSource and ChamplainCache change proposal
- From: Emmanuel Rodriguez <emmanuel rodriguez gmail com>
- To: Jiří Techet <techet gmail com>
- Cc: libchamplain-list gnome org
- Subject: Re: NetworkMapSource and ChamplainCache change proposal
- Date: Sun, 22 Nov 2009 19:07:45 +0100
On Sun, Nov 22, 2009 at 1:47 PM, Jiří Techet <techet gmail com>
I'd like to use libchamplain in my application - it will be a
satellite navigation application that uses GPS to display your current
position (something like tangoGPS, but better of course ;-).
It's nice to see libchamplain being used in different applications!
happy with what NetworkMapSource of libchamplain offers, but I'd like
to have a separate cache with a different tile-purging strategy than
the one used by libchamplain (plus some extra features).
I'm also inclined to have a more flexible cache system. I've already suggested a long time ago in irc to make the cache easier to change. This would allow us to have different cache implementations and to be able to swap them easily on a per application basis.
In the past we had a file based cache where the tiles where stored on disk. Now the cache has became an hybrid of filebase/sqlite where tiles are still stored in files but the meta data is in a sqlite db file. I wanted to have a full sqlite cache where the tiles would also be stored in the sqlite. Such cache would make it easier to copy it from one computer to another (no file system problems with paths, etc). Ideally we would also have a "ram" based cache that would just increment the ref count of the clutter actors and make the cache faster. I'm quite sure that others will also find better ways or needs for new caches.
It should even be possible to combine caches by creating a special cache class that links caches together providing a fallback mechanism. This way if the first cache tied returns a miss then the next cache will be queried and so on until a cache returns a tile. This would allow us to make nice things as to chain the ram based cache with a capacity of X tiles and have it fallback on the sqlite cache when there's a miss.
We could even go as far as to provide a mecahisnm for registering new cache implementations just as we have with the map sources but this is not so important yet. Having different cache implementations is already a big step.
Were I have a different opinion is regarding the linking of the cache within an application. I think that the cache should be tied to a ChamplainView instead of to a MapSource. The map sources should just provide the functionality to fetch new tiles and nothing else. Writting a map source should be as simple as to return a tile, implementators shoudln't be concerned with maintaining a cache. It should be the view's responsibility to query the cache first and to fallback to the map source when there's a cache miss. This way if a non network map source is one day implemented and I believe that we will have one once the Google Summer of Code project will be merged such MapSources can still benefit of the caching functionnality.
] [Thread Prev