Changes between Version 3 and Version 4 of MapGuideRfc126

Timestamp:

May 3, 2013, 6:04:53 PM (11 years ago)

Author:

jng

Comment:

--

MapGuideRfc126

@@ -220 +220 @@
 }}}
 
-and produces a response like this:
-
-{{{
-TBD
-}}}
-
-Inline selection images are rendered out as inline base64 string, avoiding an additional GETDYNAMICMAPOVERLAYIMAGE request. This exploits the new Data URI feature supported by most modern browsers, the AJAX and Fusion viewers can do the capability checks client-side to determine whether to request an inline selection. Attributes of all features are grouped by their respective layer name. 
-
-The inline image does not have the mime-type prepended to the string. It is the responsibility of the calling viewer to prepend the appropriate mime type to the base64 string in order to constitute a valid data URI. The reason for this omission is that data URIs are a browser-centric feature and would involve extra client-side processing for non-browser clients to strip out this mime type (as they probably wouldn't support or recognise data URIs)
+and produces a response like this (note the lack of attributes. Previously, this was always included whether we wanted it or not):
+
+{{{
+TBD
+}}}
+
+Inline selection images are rendered out as inline base64 string, inside the <Content> element of the <InlineSelectionImage> element, avoiding an additional GETDYNAMICMAPOVERLAYIMAGE request. This exploits the new Data URI feature supported by most modern browsers, the AJAX and Fusion viewers can do the capability checks client-side to determine whether to request an inline selection. Attributes of all features are grouped by their respective layer name. 
+
+The inline image does not have the mime-type prepended to the string. It is included as a separate <MimeType> element of the <InlineSelectionImage> element. Browsers that can support data URIs can assemble the final data URI from these components. Non-browser clients should be able to have the necessary means to process the base64 content based on the given <MimeType> value.
 
 As a result of this implementation, we are effectively batching up a series of operations server-side that previously would've been done with individual HTTP requests. Doing all this work in one shot eliminates the need for these additional requests.
 
-On the viewer front, although we can't make a true "one size fits all" model that can accommodate both viewers, we can at least provide enough information in the response for client viewers to reshape and re-project into their desired form. 
+On the viewer front, although we can't make a true "one size fits all" model that can accommodate both viewers, we can at least provide enough base information in the response for client viewers to reshape and re-project into their desired form. Some client-side processing will be required by both the AJAX and Fusion viewers.
 
 The AJAX viewer will need some slight modifications to deal with the new QUERYMAPFEATURES response as the structure differs from what is returned by getselectedfeatures.[php/jsp/aspx], but the content is the same. Selected features can be grouped by layer name and each individual selected feature has a bounding box for the "Zoom to current feature" function to work. If data URIs are supported, the viewer needs to simply check the content of the {{{InlineSelectionImage}}} property in the response. If it is not empty, it can be assigned straight into the {{{<img>}}} element that holds the selection image, otherwise we proceeed as normal and send off a GETDYNAMICMAPOVERLAYIMAGE request for that image. With the implementation of this RFC, getselectedfeatures.[php/jsp/ajax] will no longer be required and can be removed.