[geos-devel] RFC6 - Discourage use of C++ API by requiring a configure switch to install the c++ headers and SDK

[Robert Coup]

Hi Howard,

It's quite possible I read the threads out of order and assumed you'd seen
the latest/final proposal when you hadn't. Apologies - your pragmatism is
important!

On 4 October 2017 at 17:19, Howard Butler <howard at hobu.co> wrote:

>
> My pragmatism is we don't get to change the rules after we've put things
> out there and people now might depend upon us. The C++ API for GEOS
> *pre-dates* the C API.
>

Yes, maybe it's something that's made a 4.0 as a breaking compatibility
change, but that's details wrt the concept.

If the docs & the warnings and everything say "avoid the C++ API" and
there's no resources in GEOS to maintain a stable C++ API, then it's not
really "public" in a library way I think? Any more than I can grab raw
source of any OSS code and twist it to my own purposes. Possible vs Easy.


> The GEOS C API was a response to the recognition that some API insulation
> (along with a FFI-friendly interface) would be useful.
>

> It is not the library's responsibility to provide personal protective
> equipment. C++ users know the deal and accept that bargain when they use
> APIs. My note about GDAL in the previous email was to acknowledge that this
> same suggestion, to remove the C++ API, could not even be seriously
> considered there because there is so much public use of that API. There's
> even more *private* use that people probably don't know about. The same
> could be said for GEOS.
>

I'm sure there is a lot of private C++ use of GEOS, I have had some on
occasions – it's a great library! But those people are either quite capable
of `--enable-cpp-sdk` or are using an old version and not upgrading anyway?
They're clearly not using the distro GEOS packages without recompiling.

GDAL - that horse is bolted. But the time between GDAL releases and distro
packaging release can be pretty substantial because (AFAIK) of the C++ API
complexities, and that causes other problems downstream. Ending up with
people who have installs of postgis against GDAL2.0, with Mapnik against
GDAL2.2 and then another set of binaries & python bindings and What Fun™.

Packaging systems need to make decisions about moving forward with base
> versions of foundational libraries like GDAL and GEOS with acknowledgement
> that doing so may cause some laggards to be dropped. The packagers can't
> write software to update the laggards, and the libraries need the freedom
> to innovate. Attention is life, as Paul said.
>

Yeah, Debian and others sit in a difficult place with conflicting goals,
but the stronger we can make the hint of "only use the stable C API" the
better I think, so that there's *likely * to be less new software using the
C++ API, which means that distributions can roll new GEOS releases ASAP.
And yes, if there's *still *software out there and it's still not upgraded
maybe that's tough and it gets pulled from the distro. (Hopefully distros
don't enable the C++ API and put it all right back here again).

Alternative is to work with on C++ APIs/ABIs and compatibility with the
distros and make it clear that having 7 versions of GEOS installed is
completely normal. And woe betide if there's a security problem with the
WKB parser that affects them all. But that's a huge amount of effort to go
to for something the project has recommended against since forever...

Cheers,

Rob :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20171005/574adc14/attachment.html>