MS RFC 22a: Feature cache for long running processes and query processing (update)

[Frank Warmerdam]

Daniel Morissette wrote:
> You answered it yourself: "because mapserver is small, fast and 
> efficient"... at what it does best: pushing maps to the Web.
> 
> My opinion is that if we keep adding GIS processing type of features 
> we're adding complexity and getting away from the initial goal of 
> optimizing every line of code to render maps which was MapServer's 
> initial goal and the reason why *I* spent so much time on it since 2000. 
> More complexity means bloat, more chances of bugs and slowness to me.
> 
> That's why I tell people who want advanced GIS features on the Web to 
> use MapGuide and I tell people who want a transactional WFS to use 
> GeoServer: because I want to keep MapServer small, fast, efficient, 
> robust and as bug-free a possible and I don't think those features are 
> compatible with my goals.
> 
> Am I lazy and trying to avoid the problem of implementing those features 
> efficiently? Maybe... but hey, the approach has worked fairly well so far.
> 
> I'm not worried at all about the future of MapServer as long as we keep 
> it small, fast, efficient and robust. I see MapServer, MapGuide and 
> GeoServer as complementary tools and not as competitors. We have told 
> people to use GeoServer for transactional services for years and 
> MapServer has only benefited from that since we have not had to change 
> its internal data structures to deal with that problem... and as a 
> result today MapServer is still the fastest at rendering maps. This was 
> acknowledged again by the developers of both GeoServer and MapGuide in 
> the OSGeo BOF at Where 2.0 a few weeks ago.

Folks,

I agree that as a mapserver community we need to have some discussion on
what our focus is.

For me, I pretty much agree with Daniel, though I think interesting new
processing features that don't complicate normal use or interfere in the
normal processing chain are not a bad thing.  The key would be modularity
and understandability.

Based on this, I think my primary objection with RFC 22a isn't the new
geometry and layer filtering, it is that a substantial extra layer of
user visible stuff comes into play for the simple requirement of
achieving one pass query.

I think the "cache layer provider" is likely to be complicated to
understand (for developers and users) and to have unexpected performance
and behavior side effects.

Generally speaking I think we are doing fairly well at keeping MapServer
to the goal of small, fast, efficient and robust web map server.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org