Changes between Version 4 and Version 5 of MapGuideRfc19
- Timestamp:
- 03/08/07 13:19:06 (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapGuideRfc19
v4 v5 23 23 == Overview == 24 24 25 **** WORK IN PROGRESS **** 26 **** WORK IN PROGRESS **** 27 **** WORK IN PROGRESS **** 28 **** WORK IN PROGRESS **** 29 **** WORK IN PROGRESS **** 30 31 There is currently no mechanism in place to allow older clients to communicate with a newer MapGuide web tier or server and vice versa. This needs to be addressed in order to allow easier upgrade paths for end-users. 25 There is currently no mechanism in place to allow older clients to communicate with a newer !MapGuide web tier or server and vice versa. This needs to be addressed in order to allow easier upgrade paths for end-users. 32 26 33 27 == Motivation == 34 28 35 There needs to be a way for a client to be able to identify the version it is so that the web tier and server can properly communicate with it. By knowing the client version the web tier and server will be able to process the appropriate operation version and use the appropriate schema version. This will allow the web tier and server to server both old and new clients and for new clients to connect to an older web tier and server. This proposal hopes to add some form of forwards/backwards compatibility to MapGuide in order to solve this.29 There needs to be a way for a client to be able to identify the version it is so that the web tier and server can properly communicate with it. By knowing the client version the web tier and server will be able to process the appropriate operation version and use the appropriate schema version. This will allow the web tier and server to server both old and new clients and for new clients to connect to an older web tier and server. This proposal hopes to add some form of forwards/backwards compatibility to !MapGuide in order to solve this. 36 30 37 31 == Proposed Solution == … … 40 34 The new HTTP parameter has the following format: 41 35 42 MajorVersion.MinorVersion36 !MajorVersion.!MinorVersion 43 37 44 38 Example: … … 48 42 The web tier and server will be able to use this information in order to do the operation that supports the specified client version. This will allow schema changes to take place and for multiple versions of the schema to be supported because the client tells us what version it is and therefore what schema version it supports. 49 43 50 This solution only helps with newer releases of MapGuide as existing releases will not contain this forwards/backwards compatibility logic. However, the web tier/server will assume that if the HTTP parameter "CVER" is not included in the HTTP request that it is an older client and to use the oldest supported version of the operation and appropriate schema version.44 This solution only helps with newer releases of !MapGuide as existing releases will not contain this forwards/backwards compatibility logic. However, the web tier/server will assume that if the HTTP parameter "CVER" is not included in the HTTP request that it is an older client and to use the oldest supported version of the operation and appropriate schema version. 51 45 52 46 Currently, the web tier and server must always be the same version because there have been changes to the TCP/IP protocol between them that if different versions are used will cause them to no longer communicate with each other. There is already logic in place to identify this if mismatched web tier and server versions are used.
