[fdo-internals] RFC 20 for review

[Frank Warmerdam]

Thomas Knoell wrote:
> Hi,
> 
>  
> 
> RFC 20 (http://trac.osgeo.org/fdo/wiki/FDORfc20) has been posted. It 
> proposes a simplification of the FDO capability interfaces. Please 
> review the RFC and let me know of any questions and suggestions you may 
> have. The review deadline is set for end of day July 18^th.  It is 
> intended to request a vote on the RFC afterwards.

Thomas,

I'm generally supportive of this direction - mainly because I dislike the
ABI fragility of the current interface, and the need to modify every
providers when new capabilities are added.

My concerns are:

1) I believe this will break all providers until they are updated to implement
the new capabilities classes, is that right?  The doc says "Autodesk to
provide resource / funding to implement the feature for the affected
providers." but I'm concerned that there are outside providers that Autodesk
can't easily update.  Is there anything we can mitigate the transition hassles
for providers (such as a default implementation of FDOICapability that calls
the old classes)?  Can you confirm which contributed providers will be
updated by Autodesk?  (GDAL? PostGIS?  KingOracle?)

2) I'd like to know what the capability methods will return by default (
when isUnknown is going to return true).  Hopefully for something like
GetBooleanCapability() this would be false, and for the most part applications
can just check the return value and ignore isUnknown.

3) The document mentions that it was decided not to have FdoICapabilities
methods throw an exception for unknown capabilities for "performance" reasons.
Can you elaborate?  Would this really happen enough that the cost of an
exception would be high?

4) I wasn't clear on why string names for capabilities were not used.  The
(one) nice aspect of string capability identifiers is that you don't have to
maintain a master list.  So, for instance, some providers could have auxilary
capabilities that can be tested for that are unique to the provider without
having to worry about avoiding global name collisions.  The (main) downside
is that string comparisons are a bit more expensive instead of just having
switches on enumerations.

Generally speaking my concern with this RFC is that it represents a great deal
of churn for relatively modest gains.  That doesn't mean we shouldn't do it,
but it has been my experience that this sort of churn drives away contributors
to some extent.  Amoung other things, it will make it more difficult to build
providers against FDO 3.3 and FDO 3.4.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org