[fdo-internals] RFC 20 for review

Frank Warmerdam warmerdam at pobox.com
Wed Jul 9 13:34:13 EDT 2008


Dan Stoica wrote:
> Hi,
> 
> I'm not sure either this RFC promotes simplification, but something has to be done in this area. Say I find a certain provider has a limitation/some specific behavior. We create a new capability so my application (provider agnostic) is able to branch the execution. Currently we need to touch ALL the providers in order to expose the new capability. This is very annoying to say the least.
> 
> Going forward, what I suggest is to be able to get easily a capability, with minimum implementation effort (only the affected provider will be touched), like this:
> 
> FdoCapabilityType x = FdoCapabilityType_SomeNewCapability;
> Bool unknown;
> Bool supported = connection->GetCapability(x, &unknown);
> 
> Then the caller decides based on the flags:
> 
> supported   unknown
> T           T          - this case doesn't exist
> T           F          - yes, supported indeed
> F           F          - no, not supported
> F           T          - not sure (not implemented, it may be supported or not, give it a try).

Dan,

I would think that in the 4th case you ought to assume it is not
supported. If you are going to try it in this situation, you might as
well not bother asking if it supported ever and just go ahead and try it.

So my question was in particular whether we could assume some particular
return value for the unknown case, such as FALSE for getting a boolean
capability.

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



More information about the fdo-internals mailing list