[mapguide-internals] Resource Content and Response versions.
tom.fukushima at autodesk.com
Mon May 17 12:13:02 EDT 2010
See below for my understanding of how things should work...
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jackie Ng
Sent: Monday, May 17, 2010 3:49 AM
To: mapguide-internals at lists.osgeo.org
Subject: [mapguide-internals] Resource Content and Response versions.
I have some questions about the versioning of resource content and mapagent
1. Can a MapGuide Server read/write all versions of a resource content
schema? eg. Does a MGOS 2.0 server read/write LayerDefinition (v1.0.0 to
v1.2.0 and everything in between)?
[THF] By default, it can only read and write versions that are found in the server's Schemas directory. If schema validation is turned off then anything can be read or written.
[THF] Currently, we have not had to do anything that make an old schema version invalid so I believe we support all versions of all resources. This is a little tough to verify without looking at the repository history because our version numbers for new schemas does not start at 1.0.0.
[THF] In the future, there is no guarantee that this will be the case. Sometimes it is just too much effort to maintain backwards compatibility. (For example, we may want to drop symbollibraries in favor of symboldefinitions at some point---I'm not saying we're going to do this; it's just the best example of something I have right now.)
2. Is it true that the server doesn't do any resource content upgrades? Am I
assuming any upgrades are done by client applications such as MapGuide
[THF] If we need to upgrade resources from one release to the next, it could/should be an upgrade program that we provide with the server install. This program can also be run when the server starts---it could check the repository version at startup and upgrade all resources if required.
3. Does a GETRESOURCECONTENT call (from mapagent or MapGuide API) return the
resource content "as-is" without any pre-response modifications? If the
resource content contains ExtendedData elements, is it the responsibility of
the client application to determine if this ExtendedData elements make any
[THF] Yes and yes.
4. Similarly for a SETRESOURCE call (from mapagent or MapGuide API) am I
assuming the only pre-processing is the migration of unknown elements (eg.
from a newer version of an xsd schema) to ExtendedData xml elements and
adjustment of version numbers?
[THF] The web tier and server do not do any "adjustments" to the XML that is passed to it in the "SETRESOURCE" calls.
5. The AJAX Viewer has been modified to handle a new <EnablePingServer>
option introduced in WebLayout-1.1.0.xsd. If question 3 holds true, how does
this AJAX viewer handle a 1.0.0 WebLayout document?
[THF] I don't know, but if the info is not in RFC 66, I wouldn't object to someone adding it.
Is it the onus on the client application to handle these versioning issues?
[THF] Yes. So sometimes it makes sense to get rid of older versions; so that clients don't have to maintain so much baggage.
6. For non-resource content responses (eg. FdoProviderCapabilities or
SiteVersion), does the VERSION parameter determine which version of the
response I will receive? For example does a GETSITEVERSION (VERSION=1.0.0)
give me a 1.0.0 SiteVersion response? Does a VERSION=2.2.0 call give me a
[THF] Not necessarily. For example, if we rev the request version because we change the behavior of some parameters, the response may still be in the old format so there would be no need to create a new response schema version.
View this message in context: http://osgeo-org.1803224.n2.nabble.com/Resource-Content-and-Response-versions-tp5064339p5064339.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
More information about the mapguide-internals