I'd thought the "3.0" milestone and the "completed" status on that RFC would've hinted the state of this new feature :)
This is not yet tested, but if you make a new TileSetDefinition using the default provider with the same layer/group structure and finite scale list and point its tile cache path to where your old tiles are located, it should theoretically continue to serve out any cached tiles from that old location (and put any new tiles in there) should you do GETTILE requests through the new TileSetDefinition. As mentioned in the RFC, tile caches can still be wiped if you save the TileSetDefinition itself. However, if you save a Map Definition that links to a TileSetDefinition, that tile cache *should not* be wiped out. This is one of the many benefits of separating the tile set stuff out into its own resource. Now if while testing this beta release you find out what I just said is false (ie. The tile cache is being wiped when you are saving something other than the TileSetDefinition), then this is a bug that should be reported and resolved ASAP. Another thing about the XYZ provider that I didn't really explain in the blog post is that it uses a {z}/{x}/{y} physical directory structure for its tile storage. So if you wanted to, you could easily map a fully seeded XYZ tile cache directory in your web server of choice and easily consume these tiles directly via OpenLayers/Leaflet/etc with full cache headers and other goodness that a web server would normally apply for static content that is served out. The flagrant tile set invalidation problem itself is not solved for this milestone. I have a few ideas: * APIs to "lock" tile sets to prevent edits on upstream dependent resources. * Only triggering tile cache invalidation on changes of certain XML content on upstream resources (eg. The VectorScaleRange section of the Layer Definition). This way, layer changes that do not affect how a tile would look (anything not related to styles), won't trigger a blow up of the tile cache. * A hybrid of the above two solutions, where a locked tile set will prevent edits to style settings in any upstream Layer Definition but anything else goes through. I've yet to explore any of these ideas to determine feasibility. That's pretty much all the "gotchas" to be aware of. - Jackie -- View this message in context: http://osgeo-org.1560.x6.nabble.com/MapGuide-Open-Source-3-0-Beta-1-released-tp5195978p5200378.html Sent from the MapGuide Users mailing list archive at Nabble.com. _______________________________________________ mapguide-users mailing list mapguide-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapguide-users