[mapguide-internals] RFC60 finalization

[UV]

inline...
Traian Stanev wrote:
> It's implementing the simplest effective way of caching -- generally you have lots of features sharing the same style within a request and it will only parse the style once for those features. Having a global cache is more complicated because it also has to monitor changes to symbol resources -- and it would have been even more annoying to implement back when we theoretically allowed for the resource service to run on a separate machine than the mapping service.
>   
... has the plan to move the resource service to another node been 
abandonded?
If so this opens the route to more efficient use of the internal map 
structures ....

How big is the share of TileRequests in the general picture?
Maybe this is a good time to ask people for their usage patterns to 
collect some statistical usage data....

However, parallel tile requests to the same scalerange of the same map 
seem like a very popular use case ...
... and they are all sharing identical featuretypestyle data
thus I see a lot of potential to streamline the map cache structures by 
tying it more closely to the map data.

In the context of RFC60 the reuse of the symbolcache for the colorsearch 
requires some code changes due to the current scoping of the symbolcache.
A singleton based shared mapobject providing cache structures tied to 
the maps lifecycle could be a much more performant approach here.
Sharing mapdata across http requests this way could significantly 
improve server performance.

Any thoughts??
> Do you have any empirical results of a real world map showing that the current implementation results in a high relative overhead of symbol parsing compared to, say, FDO requests, or PNG saving or the symbol stylization itself?
Empirically we only know so far that 4 times a small tile takes A LOT 
longer than a tile 4 times bigger .....