Just curious - Some time ago there was a motion for RFC 76 - OGR Python drivers. Correct me if I'm wrong, but this sort of makes it easy to add python drivers? Perhaps this could be a means for others to add/reclaim a driver that gets dropped?
v/r, Mike On Wed, Jan 27, 2021 at 2:17 PM Tamas Szekeres <szeker...@gmail.com> wrote: > David, > > Up to this time the driver writers were highly welcomed to author new > drivers for the project and these effort didn't require a separate RFC in > terms of the Project Management Committee Guidelines > <https://gdal.org/development/rfc/rfc1_pmc.html> document. Adding new > drivers hasn't been considered to be substantial changes or something that > causes to change the API or brings in backwards incompatibility issues. > However in a real deployment situation the drivers may cause issues for > the developers, end users and package maintainers from several aspects like > so: > > 1. The drivers may depend on external libraries and we don't want to link > against those libraries in all cases. > 2. The external libraries may cause license incompatibilities, ie linking > against that may change the license terms of the overall project. > 3. Not all of the drivers are required in a particular solution (that > applies to the built in drivers, too). In a real situation the application > may use only a limited set of drivers and the existence of the unwanted > drivers may cause some performance degradation. > 4. Implementing custom compilations (and omitting unwanted drivers from > the build) may be problematic for most of the users or projects utilizing > gdal as a sub-project. > > In my opinion, the current solution of incubating new drivers is fairly > minimalistic, we might probably want to know what kind of format is being > addressed, who is the audience, how amount of user might be of interest, > how the licensing of the dependent project is looking like, is the > dependent project (if any) maintained well enough and can be compiled to > each supported platforms etc. > > But replying to the question, I think you shoud continue the effort, but > consider to implement a plugin build for that. There are several existing > drivers are compiled as plugins at the moment, so it should not be so > difficult. > > > Best regards, > > Tamas > > > David Brochart <david.broch...@gmail.com> ezt írta (időpont: 2021. jan. > 27., Sze, 15:29): > >> I am currently trying to add a Zarr driver to GDAL (see >> https://github.com/OSGeo/gdal/pull/3411), but from what I can see the >> trend is to remove drivers, so I'm now wondering it I should pursue this >> effort. I'm relatively new to GDAL, but from my point of view supporting a >> lot of formats is part of GDAL's success, so maybe the real focus should be >> on implementing a plugin mechanism that would allow driver development >> independently from core GDAL. Again, I might not have enough background to >> give valuable feedback. >> >> Regards, >> >> David. >> >> On Wed, Jan 27, 2021 at 12:34 PM thomas bonfort <thomas.bonf...@gmail.com> >> wrote: >> >>> >>> >>> On Tue, Jan 12, 2021 at 11:36 PM Even Rouault < >>> even.roua...@spatialys.com> wrote: >>> >>>> >>>> The issue with esoteric/legacy drivers is not that much maintenance of >>>> the >>>> actual code of the drivers, in the sense of dealing with bug reports, >>>> questions, etc. (pretty sure they are none for the ones I listed). Most >>>> of >>>> them must work reasonably well and be feature complete, and most >>>> vulnerabilities have now been fixed. My concern is that this legacy >>>> code has >>>> indirect costs on other GDAL developers and users. The psychological >>>> cost I >>>> mentionned. Let's say someone want to turn on higher warning levels, >>>> and that >>>> this breaks in tens of drivers. Would he have to ping every maintainer >>>> and >>>> wait for them to address the issue ? Or maybe he will just give up. >>>> Similarly >>>> for breaking changes in the driver API. As Sean mentionned, this is >>>> probably a >>>> serious obstacle to growing up the core development team. >>>> >>> >>> Given that we have a relatively easy way to disable individual drivers >>> at compile time, could we expand on this mechanism to mark problematic >>> drivers as "orphaned" in this case? The code would still live in the repo >>> but would be effectively disabled until someone with sufficient interest >>> invests the time/money to update the problematic code and re-enable it. >>> This will of course create some overhead to keep track of which drivers >>> have been orphaned from one release to the next, create github >>> issues/labels to list which drivers need work to be re-enabled, etc... But >>> it shifts the burden of maintaining the codebase of 250 drivers from the >>> core team over to the people/companies who actually need them. I'd be >>> willing to contribute the scripts that could ease the process of >>> orphaning/reintegrating a specific driver. >>> >>> Regards, >>> Thomas >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/gdal-dev >>> >> _______________________________________________ >> gdal-dev mailing list >> gdal-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/gdal-dev >> > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev