Changes between Version 19 and Version 20 of FDORfc20

Timestamp:

06/16/08 14:50:12 (16 years ago)

Author:

thomasknoell

Comment:

--

FDORfc20

@@ -29 +29 @@
 FDO is supposed to provide applications with a set of interfaces allowing the general implementation of tasks without taking into account whether or not the data store is a RDBMS database (Oracle, MySQL, SQL Server) or a file (SHP, SDF). Therefore, an application should not need to implement provider specific processing. However, it was reported that the current capability set is not sufficient enough to achieve this. Hence, some provider specific handling is still required. The following lists an extract of the reported use cases:
 
-    * In Autodesk Map 3D, arc elements are tessellated if the target provider cannot store arc segments. The decision on whether or not a provider supports arc handling is based on the geometry types a provider supports. The exception to this rule is Oracle. Oracle by default supports the storing of arc segments unless the current coordinate system is a Lat/Long system in which case arcs are not supported. The provider specific handling in the application is addressing this issue by first identifying whether or not Oracle is actually the target and then determining if the storing of arcs is supported based on the current coordinate system.
-    *  The utility Bulk Copy has a number of provider specific processes. One of them is to determine whether or not the target provider supports writable identity properties.
-
-In any case, the addition of a new capability can eliminate the provider specific handling currently implemented.
+    * An application may tessellate arc segments if a provider cannot handle them. To determine whether or not this is the case, the application can use a geometric capability that returns the list of supported geometry shapes a provider can process. If this information does not include arcs, the tessellation must be executed. The exception to this rule is an Oracle data store. BY default, Oracle supports storing arcs unless the current coordinate system is a Lat/Long system. In this case arcs are not supported. FDO does currently not provide any support to handle this case. Therefore, an application would have to implement provider specific processing for it.
+    * Some providers support writable identity properties. FDO currently does not indicate on a provider level whether or not this feature is supported.
+
+Both cases can be solved by introducing new capabilities which will allow for the removal of the provider specific processing.
 
 
@@ -44 +44 @@
 '''''Change the capability interface set to allow the addition of new capabilities without changing the interface set'''''
 
-To simplify capability handling as the FDO API evolves, the possibility of introducing a FDO capability interface change will be evaluated that would see the FDO API use constants to identify capabilities supported by its providers. This will make it easier to add new capabilities without changing the API every time a need arises to add a new capability. 
+The objective here is to simplify the FDO capability interfaces in that the addition of a new capability does not require FDO, providers (if they don't immediately support the new capability) and applications (if they don't use the new capability) to be rebuild.