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

[Andrew C Aitchison]

On Tue, 14 Jan 2025, Even Rouault via gdal-dev wrote:

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

If Esri released a new SDK with a changed file format,
would the SDK driver automatically write it, allowing (QGIS)
users to write the new format before OpenFileGDB catches up ?

Probably only possibly if the user updates the SDK *and* it is
binary compatible with the current one. 
Is this a likely scenario ?

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew at aitchison.me.uk