Changes between Version 9 and Version 10 of MapGuideRfc25
- Timestamp:
- Aug 9, 2007, 5:14:57 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc25
v9 v10 1 1 = !MapGuide RFC # - JSON format responses = 2 2 3 This page contains a nchange request (RFC) for the !MapGuide Open Source project.3 This page contains a change request (RFC) for the !MapGuide Open Source project. 4 4 More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page. 5 5 … … 27 27 == Motivation == 28 28 29 This is the most important part of the RFC. It describes the problem domain in detail. Focusing on this will allow reviewers to fully understand why the proposed change is being made, and potentially suggest different/better ways of accomplishing the desired results. The more time we spend on understanding the problem, the better our solution will be.30 31 29 The Fusion framework uses JSON in order to keep client side code simple (it much easier to work with than XML) and JSON is a more compact format so communication over the wire is more efficient. 32 30 … … 35 33 == Proposed Solution == 36 34 37 An additioanl OEM component has been added to the source -- jsoncpp. Jsoncpp is a C++ implementation of the JSON specification ([http://sourceforge.net/projects/jsoncpp/]). 35 The solution involves adding an extra "format" parameter on selected API invocations from the Web-tier to the Server. The "format" can be either "text/xml" or "application/json". If no parameter is specified at the Web-tier, the "format" will default to "text/xml". Due to performance considerations, two additional APIs (i.e. !DescribeSchemaAsJson and GetFDOCacheInfoAsJson) have been added to handle the special cases. 36 37 ---- 38 39 An additional OEM component has been added to the source -- jsoncpp. Jsoncpp is a C++ implementation of the JSON specification ([http://sourceforge.net/projects/jsoncpp/]). 38 40 39 41 ---- … … 89 91 # !GetVisibleMapExtent (1) [[BR]] 90 92 91 where the appended labeling scheme indicates the different implementation considerations: [[BR]] 92 (1) Web-tier changes -- every !ToXml function is matched with an !ToJson function implementation that creates a JSON document in place. [[BR]] 93 (2) Web-tier changes -- utilizes the !MgXmlJsonConvert class to convert XML documents to JSON documents. [[BR]] 94 (3) Server changes -- an extra parameter "CREFSTRING format" has been added to the respective API call; the !MgXmlJsonConvert class is used if format equals to the JSON MIME type. [[BR]] 93 where the appended labeling indicates the different implementation schemes: 94 95 (1) Web-tier changes -- every !ToXml implementation is matched with a !ToJson implementation that composes a JSON document in place. 96 97 (2) Web-tier changes -- utilizes the !MgXmlJsonConvert class to convert XML documents to JSON documents. 98 99 (3) Server changes -- an extra parameter "CREFSTRING format" has been added to the respective API call; the !MgXmlJsonConvert class is used if format is equaled to the JSON MIME type. 100 95 101 (4) Server changes -- an extra API has been added matching the respective API call (e.g. !DescribeSchemaAsXml has !DescribeSchemaAsJson as the JSON version, and GetFDOCacheInfo has GetFDOCacheInfoAsJson as its JSON specific implementation); this is because the original APIs return "STRING" and could not be efficiently adapted by the conversion process within the !MgXmlJsonConvert class implementation; and for the affected APIs, the !MgByteReader* is returned instead. 96 102 97 103 == Implications == 98 104 99 Th is section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc.105 The major changes involve differing API signatures (i.e. some functions take an extra parameter "format"). Any API invocation made to the Server will be affected. However, API calls made to the Web-tier will behave the same if the format parameter is not specified (i.e. it defaults to the "text/xml" format). Documentation should be updated to indicate that the above APIs now take an extra parameter, "format". 100 106 101 107 == Test Plan == 102 108 103 T ests need to be done after the upgrade:109 The following tests should be performed: 104 110 105 111 * Resource Service unit tests must all pass.
