Changes between Version 1 and Version 2 of FdoClientUtilities
- Timestamp:
- 10/17/07 06:53:06 (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
FdoClientUtilities
v1 v2 52 52 * Possible duplication what is available in the Platform Feature Services API. 53 53 * Duplicating the whole FDO interface – it’s almost another provider. 54 * Some things in a client-side utility library could not be added to an FDO wrapper without additions to the FDO API. An example of this is projection support.54 * Some things in a client-side utility library could not be added to an FDO wrapper without additions to the current set of FDO interfaces. An example of this is projection support. 55 55 56 56 An FDO wrapper layer could only be used in the same tier as the actual providers since that layer would be calling FDO directly. Why wouldn’t we just extend the existing platform Feature Services API instead of doing this? Possible reasons: … … 58 58 * De-coupling from platform resource services requirements. 59 59 * Deploy outside of MapGuide. 60 * A voiding stateless services, e.g. being able to control transactions via commit and rollback rather than having to set up all edits for a transaction to execute as a single call.60 * Adding capabilities not in the feature services interface, such as being able to control transactions (implies a stateful connection). 61 61 62 62 [[BR]][[BR]] 63 == 3. Functions that can be used by providers. == 63 == 3. Functions that can be used by provider writers. == 64 65 This is not quite the same as the first two options as it doesn't specifically add new capabilities outside what is available in providers, but helps provider writers add more capabilities to their providers. 64 66 65 67 A good example of this is an expression engine that a provider writer can call from within the provider that they write. The current SDF and SHP providers internally use an expression engine. Providers based on RDBMS servers don’t need to use this as the native server provides that functionality.
