Changes between Initial Version and Version 1 of FdoEnhancedVersionSupport

Timestamp:

10/18/07 08:55:45 (17 years ago)

Author:

gregboone

Comment:

--

FdoEnhancedVersionSupport

@@ +1 @@
+
+== FDO Enhanced Version Support ==
+
+=== Introduction ===
+
+This document contains a design for some software and file version handling strategies for FDO. The versions dealt by this document are:
+
+• Version of FDO software[[br]]
+• FDO provider versions[[br]]
+• XML configuration file versions[[br]]
+
+In FDO 3.0, a number of issues arose regarding the handling of these versions. There were a number of concerns as to how these versions should be handled going forward. The main purpose of this design is to resolve these issues so that customers and client applications can easily upgrade to new FDO software releases as they become available.
+
+=== Requirements ===
+
+==== FDO and Provider Versions ====
+
+The main requirement is to ensure that, when a client asks FDO to load a particular provider, the version that is loaded is compatible with the current FDO.
+
+When client stores connection information, it typically includes the provider name. This name is tied to a particular provider version.  However, this is problematic if the next major revision of the client software loads the provider for a particular connection, using the provider name stored in the client specific file.
+
+The above would attempt to retrieve the 3.0 version of the provider, which is likely binary incompatible with the next major revision of the client, which would be compatible with FDO 4.0. This can be worked around, by changing the version part of the provider name from 3.0 to 4.0, before requesting to load it. However, it would be good to streamline this so that FDO clients do not have to keep track of what all the current provider versions are. 
+
+In FDO 3.1, work was done to address this by allowing clients to omit the version parts of the provider name when requesting to load it. In this case, the latest registered version of the provider is retrieved. However, there is no guarantee that this version of the provider is binary-compatible with the current version of FDO.
+
+FDO consists of a number of core libraries (e.g. Fdo.dll, !FdoCommon.dll, etc ) plus a number of providers. Each provider handles a different type of data. The list of providers is extensible (customers can write their own). Each provider must be registered in the provider registry, in order for the FDO core to be able to find it. The provider registry can contain multiple versions of the same provider. 
+
+Clients load providers via the FDO Feature Access Manager (FAM). The client supplies the provider name and the FAM finds the provider in the registry.  The provider name can contain the name parts plus optional version number (e.g. "OSGeo.SDF" (no version), "OSGeo.SDF.3" (name plus major version), "OSGeo.SDF.3.1" (name plus major and minor version)). 
+
+Currently, the FAM retrieves the latest registered version of the requested provider. For example, if the registry contains the following providers:
+
+        OSGeo.SDF.3.0[[br]]
+        OSGeo.SDF.3.1[[br]]
+        OSGeo.SDF.3.2[[br]]
+        OSGeo.SDF.4.0[[br]]
+        OSGeo.SDF.5.0[[br]]
+
+the following table shows which provider is returned by the FAM, depending on the requested name.
+
+Client requested -------- FAM returns
+
+OSGeo.SDF ------------- OSGeo.SDF.5.0[[br]]
+OSGeo.SDF.3 ----------- OSGeo.SDF.3.2[[br]]
+OSGeo.SDF.4 ----------- OSGeo.SDF.4.0[[br]]
+OSGeo.SDF.3.1 --------- OSGeo.SDF.3.1[[br]]
+
+