[gdal-dev] Removing write side of (SDK based) FileGDB driver ?

[Even Rouault]

Hi,

You all know my ever appetite to remove useless code (especially when I 
have to do painful exercices such as RFC 105 changes). This time I'd be 
very well tempted to axe the write side of the FileGDB driver (the one 
based on the Esri SDK). Unless I'm missing something, I don't think it 
provides anything that the write side of the OpenFileGDB driver wouldn't 
provide, and it comes with various hacks to overcome shortcomings of the 
SDK (some of the hacks involve relying on the OpenFileGDB driver...). 
The read side of the FileGDB driver is still useful for compressed 
datasets, so we can't unfortunately completely kill the driver. The 
change would make the FileGDB driver skip if opened in update mode so 
that the OpenFileGDB driver kicks in instead, so this should be 
unnoticed by users of the API (thinking here of a QGIS user that would 
have the FileGDB driver installed and switching to edit mode. The 
OpenFileGDB driver should be used. I'd have to test that theory)

Thoughts?

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.