Re: NetworkMapSource and ChamplainCache change proposal

[Jiří Techet <techet gmail com>]

On Tue, Nov 24, 2009 at 09:09, Emmanuel Rodriguez
<emmanuel rodriguez gmail com> wrote:
>
>
> On Tue, Nov 24, 2009 at 12:22 AM, Jiří Techet <techet gmail com> wrote:
>>
>> On Mon, Nov 23, 2009 at 01:32, Jiří Techet <techet gmail com> wrote:
>> Just looking at what I have written I think I wasn't quite right here
>> - even when storing the tile we should do it in the same order as when
>> loading it, so
>>
>> cache1 --> cache2 --> NetworkMapSource
>>
>> For multiple map sources and caches, like
>>
>> cache1 --> cache2 --> NetworkMapSource1 --> cache3 --> cache4 -->
>> NetworkMapSource2
>>
>> NetworkMapSource1 will start storing into cache1 and NetworkMapSource2
>> into cache3.
>>
>> Actually, the more I look at how things get complicated and possibly
>> confusing, I would suggest that we should use "caches first, map
>> sources second" only strategy and not to interleave caches and map
>> sources. This will also make the interface of ChamplainView simpler
>> and less confusing.
>
> This is starting to become the Gstreamer of maps, we're just missing a
> system bus to pass messages ;)
>
> Keeping the API simpler is definitely a win. I think that most users are
> expecting to create a MapView and to set a single MapSource. Most of them
> don't care about the cache as long as it is well implemented for them and
> fast enough.
>
> I think that providing different cache implementations is already a nice
> feature. Having the cache at the View level will also be a nice addition.
> Being able to chain multiple caches and multiple views
> (cache->map->cache->map, etc) will probably be rarely used, perhaps this
> feature could wait for a future release.
>

By the way, there is one more nice application of having the
possibility to have map --> map. The latest map source in the chain
could be ErrorMapSource that will always generate the error tile (and
not delegate work to its subordinates any more). So normal map sources
will not have to care about error tile generation themselves and just
ask for a tile from its subordinate source. Also if someone wants his
own error tile - no problem - he can just create the corresponding
source and put it to the and of the chain.

> You might have a point when you say that we should only allow caches to be
> chained together and map sources with map sources. Besides if the object
> hierarchy is done right (by this I mean that Caches and MapSources share a
> comon API) an advanced user should be able to create a custom pipeline of
> caches/maps in any order as long as the user maintains its own pipeline.
>

One more interesting thing is that when looking from the outside, also
the whole chains will behave as map sources. I'm now considering also
the possibility of having a superclass that implements the code common
to all chains and derived classes like CachedMapSource (into which you
could assign your map source) that would be then plugged into the
view.

> This means that we can still provide the high level functions that give us
> the basic usage (get_cache/get_view), the advanced functions
> (clear_cache/append_cache/...) and maybe let the users build an advanced
> pipeline that they will maintain (optional).
>

Exactly. As I said in the previous paragraph, chains are just map
sources so highly specialised chains could be easily created and
plugged into the view.

> Jiří: neboj sa ja nie som katalan. Ale ako vidiš nehovorim po Česky ale po
> Slovensky (trošku), ale myslim ze rozumieš :)
> Pekny hovoriš po spanielšky.

¡Pues "wow"! (No sé como se dice "wow" en español ;-) ¡Me parece que
tu eslovaco es mucho mejor que mi español!

End of talks, time to do something. I'd really like to have it in the
next release. Actually, there is not so much coding, but rather
refactoring, so I think it could be quite easy. I'll probably do this
in two steps - first, I'll do what I originally proposed so I'll move
the stuff that belongs to cache from the map source. Then I'll know
what interface I need for caches and I can start implementing the
chain thing. Once I have some more or less usable code, I'll post it
here to get some early feedback from you. Everything depends on how
much free time I have though.

Jiri


> --
> Emmanuel Rodriguez
>