My FDO wishlist

Since it's that time of the year, and Autodesk loves them customer surveys and wishlists...

1. A way to use the FDO API in languages other than C++/.net in a multi-platform manner

FDO is a multi-platform API. I like .net, it is portable too assuming you target a safe and mature subset of the .net framework libraries (which I already do).

Unfortunately, the .net wrapper for FDO is not multi-platform and if you're not careful the .net Garbage Collector who is normally your friend, becomes your worst enemy as it prematurely cleans up your wrapped FDO objects from under your feet and you're greeted with the all-too-common AccessViolationException being thrown at you.

SWIG can wrap C++ code in a multi-platform manner. GDAL does this. MapGuide already does this, why not FDO as well? There's already a Python wrapper generated by SWIG (albeit Windows-only last I checked), so it's not exactly impossible!

I don't mind having to use C++ if I have no other choice. But higher level languages does yield greater productivity. It's how I got FDO Toolbox to become so feature-packed in such a short period of time. The fact our Linux users cannot use FDO Toolbox because of lack of flexible development options (that is not C++) is disappointing.

2. Champion SQLite as the goto flat-file format for FDO

Now I don't mean product support. Because it's already getting love from the latest releases of AutoCAD Map3D and MapGuide Studio. I mean having SQLite become the de-facto flat file format that showcases all of the features supported by FDO.

What do I mean exactly? I mean features you normally find in a RDBMS provider like:

• Association Properties
• Object Properties
• Schema Element Attributes
• etc

3. A FDO provider for MapGuide

Sure, there's no write capability built into the mapagent, but having a read-only FDO provider for MapGuide would greatly improve interoperability between FDO client applications and MapGuide. It would basically be like WFS, but without the impedance mismatch and loss of metadata. As MapGuide is built on FDO, it knows everything about FDO and the capabilities can be parameteric with respect to the underlying Feature Source.

You could possibly even have raster support by just extending existing Rendering Service APIs with required raster functionality (querying, sub-sampling, etc) and exposing this through the mapagent.

4. Consistent Schema Naming Conventions

This is already a well-documented problem, but I'll extend it with a possible solution.

For those providers that hard-code a schema name (because they don't support the concept of a logical schema and just need a name), how about instead we define the default schema name in an external configuration file and these providers can read off of this file instead? This way, not only is it unified, but unified to your preferences.

Having to write implementation-specific code in an abstraction layer like FDO defeats the whole concept!

5. Parametric Capabilities

Capability APIs break down on providers like ODBC and OGR due to their "one size fits all" nature of these providers. It would be nice if ODBC and OGR actually have capability discovery, for these capabilities to be translated to corresponding FDO capabilities, so we don't get a whole bunch of -1 values for FDO capabilities like maximum length of a property.

6. Android/iPhone support

Hey this is a wishlist after all! Smartphones are all the rage these days. No need to port everything. Just the base SDF/SHP/SQLite providers would suffice.