Changes between Version 12 and Version 13 of FDORfc20

Timestamp:

05/01/08 12:20:43 (17 years ago)

Author:

gregboone

Comment:

--

FDORfc20

@@ -23 +23 @@
 == Motivation ==
 
-The objective of this RFC is to propose enahncements to the capability interfaces of the FDO API in order that applications are able to eliminate all special case handling of FDO provider capabilities. It will be necessary to gather feedback from applications such as OSGeo !MapGuide !OpenSource and Autodesk Map 3D to determine that we have a complete set of capabilities implemented in the FDO API and that all special casing can be emininated with the proposed changes outlined in this RFC. 
+The objective of this RFC is to propose enhancements to the capability interfaces of the FDO API in order that applications are able to eliminate all special case handling of FDO provider capabilities. It will be necessary to gather feedback from applications such as OSGeo !MapGuide !OpenSource and Autodesk Map 3D to determine that we have a complete set of capabilities implemented in the FDO API and that all special casing can be eliminated with the proposed changes outlined in this RFC. 
 
-It is also necessary to introduce a previously discussed concept of !DataStore level capabilities. !DataStore capabilities are a necessity in the FDO API due to the fact that certain providers can only communicate certain capabilities that are !DataStore specific after a fullly formed connection to the provider has been established. There are cases where a provider may support a certain capability, e.g. write or long transactions, whereas a particular datastore for the current connection has limitations. E.g. it may be read only, or it may not support long transactions. Currently, there is no way for a client application to determine these datastore specific restrictions except for a few specific cases around class level capabilities.
+It is also necessary to introduce a previously discussed concept of !DataStore level capabilities. !DataStore capabilities are a necessity in the FDO API due to the fact that certain providers can only communicate certain capabilities that are !DataStore specific after a fully formed connection to the provider has been established. There are cases where a provider may support a certain capability, e.g. write or long transactions, whereas a particular !DataStore for the current connection has limitations. E.g. it may be read only, or it may not support long transactions. Currently, there is no way for a client application to determine these !DataStore specific restrictions except for a few specific cases around class level capabilities. 
 
-Finally to simplify capability handling as the FDO API evolves, we will evaluate the possibilities of introducing an API change 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.
-
+Finally to simplify capability handling as the FDO API evolves, we will evaluate the possibilities of introducing an API change 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. 
 
 == Scenarios ==