[fdo-dev] Classes and properties in SHP providers

[Frank Warmerdam]

Traian Stanev wrote:
> Not if things deteriorate to such a point that one has to handle as many
> cases as there are providers. There would be no point to FDO in such a
> case. So we have to be careful about how many capabilities we add. We
> don't want to be another DirectX (although 10 years on they are finally
> removing capabilities checking from the DirectX 10 API to ship with
> Vista)

Folks,

I'd like to backup Traian on this in a general sense.

At least in the case of the raster provider it seems like the FDO API
contains a wide variety of features with capabilities tests for most of
them.  But most of the features are things that could be implemented for
every provider with just some code (perhaps even code used from a
support library).  Making the capability optional is really unnecessary.
It just makes life harder for client implementors.

I think it should be an objective to:

  1) use capabilities to identify broad capabilities of a provider (read only,
     read write, etc)
  2) use capabilities to identify features not available in a provider because
     it is impossible with the underlying datastore, *and* we can't "paper
     over it" with extra provider code.

The objective being to reduce the number of detailed items a client
application needs to check to be portable to different providers.

I think I need to back this up with an example, and I only really have
decent knowledge of the raster providers, so forgive me for using a raster
example.

The raster provider includes a SupportsDataModel() test to see if you can
force the returned raster into a particular data model (such as asking
for the results as 32bit RGBA pixels).

For many of the data model options: pixel size in bits, color model,
tiling and interleaving organization we could provide all conversion
options for any input raster format.  All it would take would be more
code.  Done properly the code could come from a common transformation
library.

By making all of these configurations optional, we have put a high
cost onto the application to recover from limitations of the raster
provider, and do conversions itself.  It would be better for us
to just declare that providers must implement all these options.

I suspect FDO suffers from the many-providers, and only two application
syndrome.  That is, since now there are only two applications, but
there are many providers, it is better to make writing providers
easy even if it puts extra work onto the application.  But if we want
to popularize use of FDO for other applications then I think we need
to avoid this view.  In the long run we will hopefully end up with
many more applications than there are providers (as is the case for
GDAL and OGR now).

Well, this turned into a substantial diatribe.   But I would like to
encourage us all to think of what we can do with FDO to provide a
*more* (not completely) uniform set of capabilities from different
providers - especially when reading.

In the case of GDAL and OGR this has generally meant a "thicker"
layer between the provider and the application.  So that missing
capabilities can be filled in.

In the case of OGR (for reading) the capabilities tests are
mostly clues about what can be done fast, rather than what can
be done, because for reading purposes the capabilities of providers
are quite uniform.

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