[geos-devel] RFC 9: Restore C++ API as public API

Sat May 18 07:10:28 PDT 2019

Inkana,

First of all I am a 90% windows developer, so I'm well aware of the sensitivities of windows.  Guess who builds the EDB Windows PostGIS package? – ME.

I do admit I don't use C++ much so perhaps I don't fully understood the gripe that C++ API developers are complaining about.

That said what are we arguing about here? 

https://lists.osgeo.org/pipermail/geos-devel/2017-October/008109.html

We are talking about developers who want to use the C++ API adding an extra line in their script to make their intentions clear.

By making your intentions clear – you know others who want to use the C++API will be required to do so too.  Which means you most likely intend to run in a statically compiled or sandboxed environment as all have described that affects no one but users of your project (presumably users who are quite capable of compiling their own stuff) or YOU, who take on the responsibility of packaging as does SAFE Software and other companies.

L

First let me define what I mean by Public:  Projects that rely on packagers to distribute the artifacts of their project.

Everyone I talk to that is a C++ developer – I hear "But you are saying C++ API is not as important as the  C-API  and you are discouraging use of the  C++ API by calling it unstable."

What I'm saying is -  "C++ API is not AS stable (and probably be even less stable as we introduce new  C++ features) . Sure it's important but we want to change it. The C-API is the bulk of what most public projects using GEOS are using.  I think after osm2pgsql left, there are no more public projects using the C++ API. 

If more public projects were already using the C++ API I would have a different tune, but we don't so we are in a good position to enforce it before it's too late.

Thus I care more about ensuring that projects that eventually require packager support use the C-API (at least for now)  than I care about your frustration of having to add an extra line to your compile scripts"

> Because of complexity - something GEOS has an advantage. GEOS should not be used or turned into as Expert only library

Exactly and if we continue appealing to every C++ API developer gimme  "But it's a C++ API", we'll become just as complex as Boost Geometry in no time.

At this point GEOS as a C-API is more important to the general consumer than its use as a C++ API, and if C++ developers continue with this attitude of  "I don't care if it has a stable C++ API, cause I can stick with the old version if it changes too much and I compile my own stuff anyway", then the C++ API will always have an UNSTABLE caveat.  We don't even guarantee the C++ API won't change in a micro (though we try not to do that).

Thanks,

Regina

From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of lnkansa
Sent: Saturday, May 18, 2019 2:44 AM
To: GEOS Development List <geos-devel at lists.osgeo.org>
Subject: Re: [geos-devel] RFC 9: Restore C++ API as public API

For the second time, this discussion has become very passionate at some point. That being said, I believe all the package management issues being used as an excuse are more of an issue for Linux-based systems. Those who develop Linux-based applications should know better if they depend on system wide library distribution for their dependencies via some package management. For them, they should have stability in mind when doing their development. Why should a larger community pay for the poor choice of others and would have to jump through additional hoops to achieve what should be trivial in C++? I am not a Linux expert/developer and would not be in a position to judge. Such applications could consider static linking as alternative or risk being dropped by the PACKAGE MANAGERS and those who want to make their work easier. It is the responsibility of statically linked application to fix security updates. I do acknowledge most of the PSC/maintainers primary OS might be linux and might have their own preferences/biases.  

GEOS, we should not forget has a considerable number of Windows users and on windows, each application is responsible for its own "sandbox" environment. A case in point is the layout of Postgis windows distribution as an example. If there is a required security update, it is handled at the individually installed application level and not system wide. People develop their own schemes to realize how their dependencies are met. I rarely hear such issues on Windows like package management. GEOS has the ability to gain more traction if such artificial restrictions are removed.

Desktop application development stands to benefit a lot on windows - yes there are people out there using the library on windows. There is no gainsaying that those doing server application have other considerations to keep in mind. There should be nothing like "end of discussion - done" rather it should be based on facts/guidelines/practices as they are. Those who break it should pay the price. That said what, why should we prevent the C++ API for being used? Yes, it has special needs. I do not hear such arguments with GDAL. They broke the API and people had to fix their stuff did in order to use newer releases. The ABI issues as document should just be used as reference for those who complain. After all, GEOS is not LINUX kernel where such drastic considerations have their merits. Even LINUX, we have seen some positive transformations in the way Linux kernel is managed.

Some people use mostly C language for the obvious reasons. Others use C++ and are looking forward to use the high level abstractions the new standards (11, 14, 17, 20x) are providing. The interests of the minority should be respected but should not be used as an excuse to stifle innovation. Yes there is Boost Geometry as an alternative but why has it not gained traction? Because of complexity - something GEOS has a an advantage. GEOS should not be used or turned into as Expert only library. Please remember package management is a long standing issue in C/C++ based on its characteristics - those being the same that make them popular when people want primarily performance.

On Sat, May 18, 2019 at 12:23 AM Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

Mat,

I think you misunderstood me a little

> The first and third statements in the second paragraph of your response is false. 
> I have ever asked to "guarantee a stable C++ API at this point in time" or at any point ever.
> It's a fact.
> [Regina Obe] 

I never said you wanted to guarantee a stable C++ API.  And we don't have one is my point.
Something that is unstable should not be shared.  It should be statically linked or set aside for your own project and as such you shouldn't expect package maintainers to carry your project.  

> The second statement in the second paragraph of your response is also false.
> GEOS users can and do depend on the C++ API.
> It's a fact. 
No disagreement there - just don't want packagers burdened with having to ship these projects and right now we have few if any that use the C++ API
that packagers need to ship.  I'd like to keep it that way by discouraging sharing of the C++ API.  Installing headers etc -- as pramsey suggested would just open up the flood-gates of C++ projects relying on the C++-API until we have some REALLY IMPORTANT C++ project that relies on GEOS that packagers would like to ship, and expecting them to statically link every GEOS use is insane and a security hole.

I care more about packagers feeling comfortable about shipping a newer GEOS C-API and PostGIS being able to use a newer GEOS C-API than I feel about making C++ developers happy. You people have all proven to be only concerned about your self-interest and your toys.

> The arguments you present show to me you're pursuing goals of a package manager but not a programmer who wrote that code.

The way I see it Mat -- there are way more programmers than there are packagers on the GEOS / PostGIS teams, so YES I got to look out for the minority which has a major impact on the majority, because clearly no one else seems to.

> This brought incompatible toys in to the common sandbox.
What incompatible toys -- you still have your sandbox -- it's just a little more sandboxed.

> You do not want to recognize it.
I recognize it but I care much less about it than other things.  You're the one that turned in your keys to the GEOS project and said you didn't want to be part of it anymore.  I was extremely disappointed when you said that. So why this sudden new found interest?

> I'm not going to keep convincing you anymore.
Good cause we are in full agreement - we are just on opposite sides of the spectrum.

Thanks,
Regina

_______________________________________________
geos-devel mailing list
geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20190518/43bc4d2f/attachment-0001.html>