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

[lnkansa]

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> 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
> 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/ccef1da3/attachment.html>