Changes between Version 2 and Version 3 of MapGuideRfc130
- Timestamp:
- 01/03/13 02:34:14 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc130
v2 v3 9 9 ||RFC Template Version||(1.0)|| 10 10 ||Submission Date||18 Dec 2012|| 11 ||Last Modified|| ||11 ||Last Modified||3 Jan 2013|| 12 12 ||Author||Jackie Ng|| 13 13 ||RFC Status||draft|| … … 24 24 == Overview == 25 25 26 This RFC proposes to add support for streaming feature/aggregate/SQL query results over the HTTP mapagent .26 This RFC proposes to add support for streaming feature/aggregate/SQL query results over the HTTP mapagent in a memory-efficient manner. 27 27 28 28 == Motivation == … … 35 35 * JSON: 1.5GB (!!!) 36 36 37 And this is just for one request. If we want MapGuide to be a useful '''data''' platform, one that can support [http://osgeo-org.1560.n6.nabble.com/OpenLayers-SVG-MapGuide-Vector-Viewer-td4210812.html a theoretical map viewer that does full client-side rendering], our methods of querying data from it must be efficient . What we currently have in place is not acceptable.37 And this is just for one request. If we want MapGuide to be a useful '''data''' platform, one that can support [http://osgeo-org.1560.n6.nabble.com/OpenLayers-SVG-MapGuide-Vector-Viewer-td4210812.html a theoretical map viewer that does full client-side rendering], our methods of querying data from it must be efficient in both performance '''and memory use'''. What we currently have in place is not acceptable. 38 38 39 39 == Proposed Solution == … … 132 132 }}} 133 133 134 The proxy versions of these readers (MgProxyFeatureReader/MgProxyDataReader/MgProxySqlDataReader) provides implementations of these methods to return the various XML fragments that compose the default XML response. 134 The proxy versions of these readers (MgProxyFeatureReader/MgProxyDataReader/MgProxySqlDataReader) provides implementations of these methods to return the various XML fragments that compose the default XML response. Server implementations will never have these methods called, so they will throw an exception if invoked. 135 135 136 136 To explain what these new internal APIs are supposed to do, here's the current implementation of MgProxyDataReader::ToXml() … … 273 273 * WFS GetFeature responses 274 274 275 KML rendering internally buffers KML content at the Renderer/Stylization level. To facilitate true '''streamed''' KML content would require refactoring of the KmlRenderer and/or the Rendering/Stylization architecture. Supporting streamed KML responses would have to be the scope of another separate RFC .276 277 WFS GetFeature responses is handled by MapGuide's OGC templating engine. This templating engine suffers from the same problem of internally buffering the full WFS GetFeature response up-front. What's worse is that this internal buffering is backed by the MgByte class that has a hard-coded limit of 64MB. Although rare, WFS queries that result in over 64MB of buffered data will be truncated (see #1070). Supporting streamed WFS GetFeature responses is a monumental task in itself due to the design and use of the templating engine and would have to be the scope of a separate RFC .275 KML rendering internally buffers KML content at the Renderer/Stylization level. To facilitate true '''streamed''' KML content would require refactoring of the KmlRenderer and/or the Rendering/Stylization architecture. Supporting streamed KML responses would have to be the scope of another separate RFC if we want to go down this path. 276 277 WFS GetFeature responses is handled by MapGuide's OGC templating engine. This templating engine suffers from the same problem of internally buffering the full WFS GetFeature response up-front. What's worse is that this internal buffering is backed by the MgByte class that has a hard-coded limit of 64MB. Although rare, WFS queries that result in over 64MB of buffered data will be truncated (see #1070). Supporting streamed WFS GetFeature responses is a monumental task in itself due to the design and use of the templating engine and would have to be the scope of a separate RFC if we ever want to go down this path. 278 278 279 279 == Test Plan == 280 280 281 Exercise the affected operations against the Apache/ISAPI/CGI agents. Verify the XML/JSON content is the same for all 3 agents and is thematches the content as it was before this RFC.281 Exercise the affected operations against the Apache/ISAPI/CGI agents. Verify the XML/JSON content is the same for all 3 agents and matches the content as it was before this RFC. 282 282 283 283 == Funding / Resources ==