Re: NetworkMapSource and ChamplainCache change proposal

[Jiří Techet <techet gmail com>]

Hello Emmanuel,

your idea of having cache attached directly to ChamplainView makes a
lot of sense - this is what I expected and was a bit surprised that it
was attached to MapSource after looking at the source code. Caches and
MapSources should be independent to make it easy to implement a new
cache or MapSource and not having to care about the other. I made the
original proposal just not to change too many things. I also like your
idea of having a chain of caches (not sure if it will ever be used in
practice, but it makes things more elegant). After thinking about it a
little, I believe we could do the following:

Notice that Cache is basically a MapSource - it's a source whose tiles
are stored offline and, in addition, you can store some tiles into it.
So we could inherit a cache from MapSource + add the extra methods for
storing tiles. Now, for fill_tile(), we could use the chain of
responsibility like this:

ChamplainView --> cache1 --> cache2 --> NetworkMapSource

(Where the number of caches is arbitrary, or even 0, and the last in
the chain is NetworkMapSource.) If the tile is not present in cache1,
it asks the next one in the chain and so on. When it reaches
NetworkMapSource, it will load the tile from the network and a reverse
procedure will occur to store the tile into a cache:

NetworkMapSource --> cache2 --> cache1

(This means that caches would have to contain references to MapSources
and vice versa.) If cache2 doesn't want to store the tile, it just
delegates the work to cache1.

Other functions of MapSource (like
champlain_map_source_get_longitude()) will be simply delegated to
subordinate caches until they they reach NetworkMapSource which will
be the one that returns the value. Notice that this solution is very
elegant for ChamplainView - it doesn't have to care whether it is
attached to a cache or a NetworkMapSource - it will always do the very
same thing.

After thinking about it this looks as a much more elegant solution so
I'm inclined to implement this one. Your opinion?

Thanks,

Jiri



On Sun, Nov 22, 2009 at 19:07, Emmanuel Rodriguez
<emmanuel rodriguez gmail com> wrote:
>
>
> On Sun, Nov 22, 2009 at 1:47 PM, Jiří Techet <techet gmail com> wrote:
>>
>> 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!
>
>>
>> I'm quite
>> 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[1].
> 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.
>
> [1]
> http://www.gitorious.org/~potyl/libchamplain/potyl-perl/commits/cache-full
> --
> Emmanuel Rodriguez
>