<div dir="ltr"><div class="gmail_extra"><span style="font-size:12.8px">Hi Howard, </span><div class="gmail_extra" style="font-size:12.8px"><br></div><div class="gmail_extra" style="font-size:12.8px">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!</div><span class="gmail-im" style="font-size:12.8px"><div class="gmail_extra"><br></div><div class="gmail_extra">On 4 October 2017 at 17:19, Howard Butler <span dir="ltr"><<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br></div></span><div class="gmail_extra" style="font-size:12.8px"><div class="gmail_quote"><span class="gmail-im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class="gmail-m_9194407455956115825gmail-"><br></span><div>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.</div></div></blockquote><div><br></div></span><div>Yes, maybe it's something that's made a 4.0 as a breaking compatibility change, but that's details wrt the concept.</div><div><br></div><div>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.</div><span class="gmail-im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">The GEOS C API was a response to the recognition that some API insulation (along with a FFI-friendly interface) would be useful. </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div>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.</div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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™.</div><span class="gmail-im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">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.<br></div></blockquote><div><br></div></span><div>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 <i>likely </i> to be less new software using the C++ API, which means that distributions can roll new GEOS releases ASAP. And yes, if there's <i>still </i>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).</div><div><br></div><div>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...</div><div><br></div><div>Cheers,</div><div><br></div><div>Rob :)</div></div></div></div></div>