Changes between Version 3 and Version 4 of MapGuideRfc19


Ignore:
Timestamp:
Mar 8, 2007, 1:18:10 PM (17 years ago)
Author:
brucedechant
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • MapGuideRfc19

    v3 v4  
    3333== Motivation ==
    3434
    35 There needs to be someway for a client to be able to identify the version it is so that the web tier and server can properly communicate with it. This proposal hopes to add some form of forwards/backwards compatibility to MapGuide in order to solve this.
     35There 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.
    3636
    3737== Proposed Solution ==
    3838
    39 Client Changes:
     39A new HTTP parameter "CVER" needs to be added to all HTTP requests. This new parameter will be used to identify the client version.
     40The new HTTP parameter has the following format:
    4041
    41 Clients like MapGuide Studio will need to add the following HTTP parameter:
    42 
    43 CVER=MajorVersion.MinorVersion
     42MajorVersion.MinorVersion
    4443
    4544Example:
    … …  
    4746CVER=1.2
    4847
    49 The web tier and server will be able to use this information in order to do the operation that uses that 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.
     48The 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.
    5049
    51 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 a CVER is not included in the HTTP operation that it is an older client and to use the oldest supported version of the operation.
     50This 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.
    5251
    53 The web tier and server must always be the same version because there could be changes to the TCP/IP protocol between them that could cause them to no longer comuunicate. There is already logic in place to identify this i
     52Currently, 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.
    5453
    5554== Implications ==
    5655
    57 The web tier and server will now be able to recognize clients and will be able to give the proper response, as long as, they support the version of the client.
     56The web tier and server will now be able to recognize different client versions and will be able to give the proper response, as long as, they support the version of the client.
    5857
    5958== Test Plan ==