Changes between Initial Version and Version 1 of MapGuideRfc21

Timestamp:

May 29, 2007, 1:37:13 AM (17 years ago)

Author:

ksgeograf

Comment:

--

MapGuideRfc21

@@ +1 @@
+= !MapGuide RFC 21 - Expose functionality for manipulating Runtime map, using Xml format =
+
+This page contains a change request (RFC) for the !MapGuide Open Source project.  
+More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page.
+
+== Status == 
+ 
+||RFC Template Version||(1.0)|| 
+||Submission Date||May 7, 2007||
+||Last Modified||Kenneth, GEOGRAF A/S [[Timestamp]]||
+||Author||Kenneth, GEOGRAF A/S||
+||RFC Status||draft||
+||Implementation Status||pending||
+||Proposed Milestone||1.3||
+||Assigned PSC guide(s)||||
+||'''Voting History'''||||
+||+1||||
+||+0||||
+||-0||||
+||-1||||
+ 
+== Overview ==
+
+This RFC exposes some existing functionality as well as some new functionality for manipulating the runtime map.
+
+== Motivation ==
+
+The map definition is Xml based, and easy to manipulate. The runtime map is in binary format, and tightly tied to the inner workings of the MapGuide server. It should be expected that the current format will change over time, thus breaking compatibility with external binary reader/writer applications.
+
+When using the current MapGuide API, the code for creating and maintaining the runtime map is found in code shared by the server and the API. This means that an application must be adapted to fit a specific version of the MapGuide server. Or at least have the correct version of the codebase (eg. dll's).
+
+== Proposed Solution ==
+
+There already exists code in the server to create a runtime map from a map defintion.
+There should be two more functions in the MgMap class:
+{{{
+void MgMap::UpdateRuntimeMap(MgResourceService* resourceService, MgResourceIdentifier* mapDefinition, CREFSTRING mapName);
+void MgMap::UpdateMapDefinition(MgResourceService* resourceService, MgResourceIdentifier* mapDefinition, CREFSTRING mapName);
+}}}
+
+The UpdateMapDefinition should just overwrite the mapDefinition with the current runtimemap.
+The UpdateRuntimeMap should try to sync the runtime map, by settings map properties. This will allow the current change-list scheme to work.
+
+These two functions should be exposed in the HttpHandler, along with the existing MgMap::CreateMap(...).
+
+== Considerations ==
+
+This is prone to a race condition, as the client must get a copy of the runtime map, update it, and write it back. There is currently a generation scheme, at least with the Ajax viewer. This can be used to catch such problems.
+
+There may be an unwanted overhead, as the mapDefinition must be written to the server, resulting in the following scenario:
+{{{
+Call UpdateMapDefinition
+Download MapDefinition
+Modify map on client
+Upload MapDefintion
+Call UpdateRuntimeMap
+}}}
+
+In some cases it might be more efficient to use these three variants:
+{{{
+void MgMap::UpdateRuntimeMap(MgResourceService* resourceService, MgByteReader* mapDefinitionAsXml, CREFSTRING mapName);
+MgByteReader* MgMap::MapDefinitionFromRuntimeMap(MgResourceService* resourceService, CREFSTRING mapName);
+void MgMap::CreateMap(MgResourceService* resourceService, MgByteReader* mapDefinitionAsXml, CREFSTRING mapName);
+}}}
+
+Which could reduce the number of service calls from 4 to 2:
+{{{
+Call MapDefinitionFromRuntimeMap
+Modify map on client
+Call UpdateRuntimeMap
+}}}
+
+== Implications ==
+
+This RFC is strictly an API enhancement. If the update to the runtime map, is done as a "diff" on the current map (as opposed to overwrite), there should be no compatibility problems. Any errors in this code, will effect only applications using this extension. Worst case would be a corrupted runtime map.
+
+== Test Plan ==
+
+Write a small test application that calls the functions through the HttpHandler. Should be very easy to test.
+
+== Funding/Resources ==
+
+Community contributed enhancement.