[gdal-dev] Considering drivers removal ?

[Kurt Schwehr]

I am definitely for removing unused things that talk to servers or use
binary drivers.

I can see wanting to keep drivers that don't interact with servers for
posterity, but I think that cost is starting to get high.  A system like
you describe with a good lead time sounds good.

In the Google setup, I switched to using the set of minimum viable drivers
for business needs in our internal build.  The cost of having other drivers
was just too much. We have issues with custom filesystem support, tracking
of things that go through sandbox boundaries, and maximum binary size
(nothing like having your compiler bail from an OOM).


On Sun, Jan 10, 2021 at 3:02 PM Even Rouault <even.rouault at spatialys.com>
wrote:

> Hi,
>
> It's not spring yet, but I'm in a mood lately of axing useless things, and
> we
> probably have tons of candidate for that in GDAL, especially in drivers.
> I was going to just axe the DB2 driver
> (https://github.com/OSGeo/gdal/pull/3366) but the issue is more general.
>
> Any idea how we can know what is used and what isn't ? A "call-home"
> functionality where we would track driver usage would only be acceptable
> if
> people enable it and have network connectivity, so we won't probably get
> lots
> of feedback. Having a spreadsheet with the driver list and asking people
> to
> fill it would probably also receive little feedback. So the idea I had was
> to
> do something like the following in the Open() method of a candidate for
> removal:
>
> GDALDataset* FooDriver::Open( .... )
> {
>    if( !Identify(poOpenInfo) )
>       return nullptr;
>
>    if( !CPLTestBool(CPLGetConfigOption("GDAL_ENABLE_DRIVER_FOO", "NO") )
>    {
>        CPLError(CE_Failure, CPLE_AppDefined,
>     "Driver FOO is considered for removal in GDAL 3.5. You are invited "
>     "to convert any dataset in that format to another more common one ."
>     "If you need this driver in future GDAL versions, create a ticket at "
>     "https://github.com/OSGeo/gdal (look first for an existing one first)
> to "
>     "explain how critical it is for you (but the GDAL project may still "
>     "remove it), and to enable it now, set the GDAL_ENABLE_DRIVER_FOO "
>     "configuration option / environment variable to YES");
>        return nullptr;
>     }
>     ...
> }
>
> That is, when we detect a file to be handled by the driver, emit the above
> error message and do not open the dataset, unless the user defines the
> environment variable.
> Similarly in the Create()/CreateCopy() methods.
> If we ship this in 3.3, with a 3.5 milestone for removal, this would offer
> a
> feedback period of one year / 2 feature versions.
>
> Here's my own list of candidates for retirement (probably
> over-conservative).
> Mostly based on gut feeling. None of them are particularly bad citizens,
> but I
> have no indication that they are still used, which doesn't mean they
> aren't.
>
> * Raster side:
> BPG
> DB2Raster
> DOQ1
> DOQ2
> E00GRID
> Epsilon
> FujiBAS
> GS7BG
> GSAG
> IDA
> JDEM
> JPEG2000 (Jasper): JP2OpenJPEG is a better replacement
> JPEGLS
> LAN
> MFF
> MG4Lidar ?
> NDF
> NTv1
> SDTS Raster
> SGI
> XPM
> ZMap
>
> * Vector side:
> AERONAVFAA
> ESRI ArcObjects
> ARCGEN
> BNA
> Cloudant
> CouchDB
> DB2
> DODS
> FMEObjects Gateway
> Geomedia MDB
> GMT ASCII Vectors
> GTM
> HTF
> INGRES
> MongoDB (the old one, superseded by MongoDBv3)
> OpenAIR
> REC
> SDTS
> SUA
> SVG
> TIGER
> WALK
>
>
> Anything you'd add / remove ?
>
> What is not obvious is what would be the criterion for keeping a driver:
> 1,
> 10, 100 users asking for the driver to be kept ?
> If a GDAL developer contributing to the overall good of the project needs
> the
> preservation of a driver to be able to justify its continued involvement,
> I'd
> tend to think it to be enough to keep it.
>
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210110/61ec0df5/attachment-0001.html>