[fdo-internals] RFC 20 for review

[Thomas Knoell]

Hi Frank,

Thanks for the comments. Please see inline for answers to your questions/comments.

Thanks

  Thomas

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam (External)
Sent: Tuesday, July 08, 2008 8:08 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RFC 20 for review

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?)

[tok]: The plan is to update all providers including GDAL, PostGIS and KingOracle to include the new class. It is further intended to ensure that the new interfaces return the correct values for each of the currently available capabilities. There is also a template that will be made available containing a default implementation of the class that can be added to other providers that we won't be able to change. Once the template is added, those providers will work with the new FDO code base. The user may have to adjust some of the capability values to reflect the provider settings. There is no plan to reference the existing capability class functions as the intent is to deprecate them at some point. With the planned updates and the template, all providers should be able to work with the new FDO code base.


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.

[tok]: The default values returned in case the requested capability is unknown are:

        GetBooleanCapability:   false
        GetInt32Capability:     0
        GetInt64Capability:     0
        GetStringCapability:    NULL
        GetArrayCapability:     NULL
        GetObjectCapability:    NULL

I'll update the RFC to include this information.


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?

[tok] The issue with exceptions was to actually handle them in the calling code correctly. In FDO, all a caller gets is an exception message. To correctly identify an unknown-capability error the caller would have to do a string comparison of the returned message with the expected message for such a scenario. This is a costly approach. You most likely are correct in that in a lot of cases this may not be a factor. But with the proposed concept, we get the same result in a cheaper way. And for coding purpose, it is easier to handle than exceptions.


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.

[tok] First, I like to point out that there is no master capability list that is required to be maintained. The proposed enumerations should be regarded as a snapshot of available capabilities at that time. Adding a provider capability does not require updating that enumeration. If this would be the case then we would not achieve the goal we are aiming for. And if you look at the API you see that the enumeration is not referenced in any place. Again, consider the enumeration as a helper for a developer to get some support on what capabilities are available.

As for string versus number, the main reason to use a number was that it is less costly (string comparison) to use. And it does not prevent you from defining auxiliary capabilities for providers. Whether or not strings are easier to use in such a scenario is something else but in any case you have to have a certain unique mechanism in place to avoid duplication. With strings, you may decide to use the provider name (or an abbreviation of it) as a prefix. With numbers, you can define a number range for a provider to achieve the same. But I am flexible here.


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

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals