[fdo-internals] Re: FDO RFC 54 is ready for review.

[Jackie Ng]

I guess my main beef with the OGR provider is two things:

1. The implementation of the FDO capability interfaces in the OGR provider
is not parametric with respect to the underlying OGR driver. 

Take a look
(http://trac.osgeo.org/fdo/browser/trunk/Providers/OGR/OgrProvider.h). Lots
of hard-coded values being returned there. 

A well-behaved FDO client application may run into assumptions (as a result
of FDO-OGR impedance mismatch) that may not apply. I think the ODBC provider
suffers from this problem too (as would any other provider that is an
adapter to an existing data access API)

2. That it just seems so unstable when consumed via the managed .net
wrapper. Trying to work with MapInfo files from FDO Toolbox using the OGR
provider has been painful.

I do like the idea of an OGR "core" from which specialized providers can
spring from, kind of like how the RDBMS providers are derived from the same
(GenericRdbms) core.

At the end of the day, I'd like a quick and accessible way for end users of
FDO client applications to access MapInfo files. I believe this RFC
satisfies this objective. 

Unfortunately, it is apparent that I am not qualified enough to argue the
case on its technical merits (due to my lack of knowledge regarding OGR and
the MapInfo file format), so this is probably my last contribution to this
discussion.

- Jackie


-- 
View this message in context: http://osgeo-org.1803224.n2.nabble.com/FDO-RFC-54-is-ready-for-review-tp5673351p5677054.html
Sent from the FDO Internals mailing list archive at Nabble.com.