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

[Regina Obe]

> On Thu, May 16, 2019 at 04:28:05PM -0500, Mateusz Loskot wrote:
> > Dear All,
> >
> > I'd like propose to effectively revert the RFC 6:
> >
> > https://trac.osgeo.org/geos/wiki/RFC9
> >
> > I'll appreciate if the PSC members considered to review my proposal
> > and arranged the voting.
> >
> > Although I've made my best to prepare the write short, clear and
> > unambiguous proposal, I'll welcome your feedback.
> 
> Excuse me, maybe I lost some changes, but the C++ API was still available
as
> public API. RFC6 was never implemented, as not passed.
> 
> The only change related to the mentioned mailing list thread, that I'm
aware
> of, is commit aae36582e743505c863c5767e5989da48f84d5a6,
> which introduced a compiler WARNING emitted (togheter with instructions on
> how to hush it) when _building_ applications using the C++ API of GEOS.
> 
> Please correct me if I'm wrong
> 
> REF: https://git.osgeo.org/gitea/geos/geos/commit/aae36582e
> 
> --strk;
[Regina Obe] 
I always assumed that's what we were arguing about the actual commit.
https://lists.osgeo.org/pipermail/geos-devel/2017-October/008114.html

But the RFC 6 - went back and forth back and forth -
https://trac.osgeo.org/geos/wiki/RFC6  -- so it needs to be rewritten a bit
to reflect the actual reality and probably just passed to minimize on
confusion.

I even thought Mat was on board with the change when we discussed a year and
half ago:

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

But was hung up on the words -- DEPRECATE   which we did not use.  We used
"GEOS C++ API is unstable" which Mat thought was so intuitively obvious to
not be worthy of mention in any mode in which any developer would be forced
to read it to proceed.

FWIW I think Greg's comments were more "here's the points"  with much less
emotion than we've exhibited the past couple of days.
https://lists.osgeo.org/pipermail/geos-devel/2017-October/008082.html
I don't know if we should provide a link with a long drawn out discussion of
why you should or should not use the C++ API?  (Like is GEOS C++ API for
you?) as it does make a lot of sense to use in many circumstances.


Thanks,
Regina



___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Greg Troxel]

lnkansa  writes:

> 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.

This is not about GNU/Linux vs other packaging systems.  It is about the
notion that it is normal and proper to use dynamic linking and only have
one copy of a library, such that it can be updated for security issues
without having to update large amounts of other things.

Part of the problem, perhaps most of it, is that programs written in C++
tend not have a stable ABI.  With a notion of ABI stability, I think
most of the objections would be less strong.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Sandro Santilli]

On Thu, May 16, 2019 at 04:28:05PM -0500, Mateusz Loskot wrote:
> Dear All,
> 
> I'd like propose to effectively revert the RFC 6:
> 
> https://trac.osgeo.org/geos/wiki/RFC9
> 
> I'll appreciate if the PSC members considered to review my proposal
> and arranged the voting.
> 
> Although I've made my best to prepare the write short,
> clear and unambiguous proposal, I'll welcome your feedback.

Excuse me, maybe I lost some changes, but the C++ API was still
available as public API. RFC6 was never implemented, as not passed.

The only change related to the mentioned mailing list thread,
that I'm aware of, is commit aae36582e743505c863c5767e5989da48f84d5a6,
which introduced a compiler WARNING emitted (togheter with
instructions on how to hush it) when _building_ applications using
the C++ API of GEOS.

Please correct me if I'm wrong

REF: https://git.osgeo.org/gitea/geos/geos/commit/aae36582e

--strk;
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Sandro Santilli]

On Fri, May 17, 2019 at 07:34:13PM +0200, lnkansa wrote:

> While I do appreciate the work of the library developers, I do support that
> fact that C++ API is made available for the larger community.

I might have missed recent changes but isn't it that we're still
making it available and just raising a compiler WARNING when including
the C++ headers, with hints telling you how to hush those warnings ?

That means the C++ API is still made available...

--strk;
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

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-boun...@lists.osgeo.org] On Behalf Of 
lnkansa
Sent: Saturday, May 18, 2019 2:44 AM
To: GEOS Development List 
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

Re: [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  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 

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

[Regina Obe]

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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Mateusz Loskot]

Regina,

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.

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.

The arguments you present show to me you're pursuing goals of a package
manager but not a programmer who wrote that code.
This brought incompatible toys in to the common sandbox.
You do not want to recognise it.

I'm not going to keep convincing you anymore.
I've run out of rational arguments.


Mateusz Loskot, mate...@loskot.net
(Sent from mobile)


P. S. There is really no need for the epithets


On Fri, 17 May 2019, 14:13 Regina Obe,  wrote:

>
>
> I'm a developer and a package manager (inside Google and somewhat still
> around for fink on mac)...
>
>
>
> I count on both the C and C++ APIs for many projects.  Projects needing
> ABI stability know they need to stick to C interfaces.
>
>
>
> For those of us packagers that "live at head" (well mostly...), we know
> that ABI stability is out the window and it's up to us to manage things
> carefully.
>
>
>
> I've been successfully doing C++ management with GEOS and GDAL for many
> years.  It seems reasonable for debian to only support C, but please don't
> rule out C++ for others.  For me, C++ APIs are radically better than C for
> large scale work (aka google) and I really really don't want more
> custom/external to the package C++ wrappers for C (with or without wrapping
> C++).
>
>
>
> http://schwehr.org
>
> *[Regina Obe] *
>
>
>
> I don't think we should discuss this any further until at least GEOS 3.8
> is out.  As we said the C++ API may drastically change in GEOS, so if you
> are relying on it – you should be SEVERELY warned.  We have not taken away
> your ability to use it, so I'm not sure what all the fuss is about here.
> We just want to discourage sharing it (via the unstable C++ API).  If you
> live on the head – you compile everything on the head so you can be as
> unstable as you want.
>
>
>
> We said the C++ API is unstable and we aren't willing to put in the effort
> to guarantee a stable C++ API at this point, so NO it is not a first class
> citizen.  Something you can't depend on is NOT a first class citizen.
> Maybe in the future but NOT NOW.
>
>
>
> If you want fancy C++ niceties go use Boost Geometry -  I hear their
> hipster C++ developers.
>
>
>
>
>
>
>
> Thanks,
>
> Regina
>
>
>
>
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-development



On Fri, 17 May 2019, 14:13 Regina Obe,  wrote:

>
>
> I'm a developer and a package manager (inside Google and somewhat still
> around for fink on mac)...
>
>
>
> I count on both the C and C++ APIs for many projects.  Projects needing
> ABI stability know they need to stick to C interfaces.
>
>
>
> For those of us packagers that "live at head" (well mostly...), we know
> that ABI stability is out the window and it's up to us to manage things
> carefully.
>
>
>
> I've been successfully doing C++ management with GEOS and GDAL for many
> years.  It seems reasonable for debian to only support C, but please don't
> rule out C++ for others.  For me, C++ APIs are radically better than C for
> large scale work (aka google) and I really really don't want more
> custom/external to the package C++ wrappers for C (with or without wrapping
> C++).
>
>
>
> http://schwehr.org
>
> *[Regina Obe] *
>
>
>
> I don't think we should discuss this any further until at least GEOS 3.8
> is out.  As we said the C++ API may drastically change in GEOS, so if you
> are relying on it – you should be SEVERELY warned.  We have not taken away
> your ability to use it, so I'm not sure what all the fuss is about here.
> We just want to discourage sharing it (via the unstable C++ API).  If you
> live on the head – you compile everything on the head so you can be as
> unstable as you want.
>
>
>
> We said the C++ API is unstable and we aren't willing to put in the effort
> to guarantee a stable C++ API at this point, so NO it is not a first class
> citizen.  Something you can't depend on is NOT a first class citizen.
> Maybe in the future but NOT NOW.
>
>
>
> If you want fancy C++ niceties go use Boost Geometry -  I hear their
> hipster C++ developers.
>
>
>
>
>
>
>
> Thanks,
>
> Regina
>
>
>
>
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

 

I'm a developer and a package manager (inside Google and somewhat still around 
for fink on mac)...

 

I count on both the C and C++ APIs for many projects.  Projects needing ABI 
stability know they need to stick to C interfaces.

 

For those of us packagers that "live at head" (well mostly...), we know that 
ABI stability is out the window and it's up to us to manage things carefully.

 

I've been successfully doing C++ management with GEOS and GDAL for many years.  
It seems reasonable for debian to only support C, but please don't rule out C++ 
for others.  For me, C++ APIs are radically better than C for large scale work 
(aka google) and I really really don't want more custom/external to the package 
C++ wrappers for C (with or without wrapping C++).

 

http://schwehr.org

[Regina Obe] 

 

I don't think we should discuss this any further until at least GEOS 3.8 is 
out.  As we said the C++ API may drastically change in GEOS, so if you are 
relying on it – you should be SEVERELY warned.  We have not taken away your 
ability to use it, so I'm not sure what all the fuss is about here.  We just 
want to discourage sharing it (via the unstable C++ API).  If you live on the 
head – you compile everything on the head so you can be as unstable as you 
want.  

 

We said the C++ API is unstable and we aren't willing to put in the effort to 
guarantee a stable C++ API at this point, so NO it is not a first class 
citizen.  Something you can't depend on is NOT a first class citizen.  Maybe in 
the future but NOT NOW.

 

If you want fancy C++ niceties go use Boost Geometry -  I hear their hipster 
C++ developers.

 

 

 

Thanks,

Regina

 

 

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Kurt Schwehr]

I'm a developer and a package manager (inside Google and somewhat still
around for fink on mac)...

I count on both the C and C++ APIs for many projects.  Projects needing ABI
stability know they need to stick to C interfaces.

For those of us packagers that "live at head" (well mostly...), we know
that ABI stability is out the window and it's up to us to manage things
carefully.

I've been successfully doing C++ management with GEOS and GDAL for many
years.  It seems reasonable for debian to only support C, but please don't
rule out C++ for others.  For me, C++ APIs are radically better than C for
large scale work (aka google) and I really really don't want more
custom/external to the package C++ wrappers for C (with or without wrapping
C++).

On Fri, May 17, 2019 at 10:34 AM lnkansa  wrote:

> NON PSC:
> While I do appreciate the work of the library developers, I do support
> that fact that C++ API is made available for the larger community. C++ is
> enjoying Renaissance (11, 14, 17, 20) and attempts to "force" downstream
> developers to use the the C-API rather decreases programmer productivity. A
> good example would be the use of unique_ptr for resource management - it is
> as good as it gets. Why not just use it as it is intended? After all, there
> are always a thousand ways to compile a library with different compiler
> switches. That is a beauty and also a pain - This is what partly defines
> our DNA. Stable projects would always use CAPI knowing the consequences.
> Anyone who opens up the hood should know what he is doing and if the person
> shoots himself in the foot so be it. Those using C++ would have to compile
> anyway. OSS projects that take such dependencies are the ones that should
> pay the price and not the other way around. If their usage breaks your
> packaged distro, they should pay the price of being dropped. After all
> engineering is about choices. Please bring the C++ API back a first class
> citizen.
>
> On Fri, May 17, 2019 at 4:53 PM Sebastiaan Couwenberg 
> wrote:
>
>> On 5/17/19 4:43 PM, Mateusz Loskot wrote:
>> > On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg 
>> wrote:
>> >> On 5/17/19 3:23 PM, Andrew Bell wrote:
>> >>> Frequent, breaking API changes seem a problem. ABI changes seem more
>> like a
>> >>> small annoyance. I can understand how a stable ABI would be nice, but
>> I
>> >>> personally don't think it's more important than a good interface for
>> >>> library users.
>> >>
>> >> And that's the difference in perspective between a developer and
>> >> distribution packager.
>> >
>> > It is not my role of a library developer to make packaging easier.
>> > There are many PMs and PDMs, OS-specific, distro-specific
>> > as well as number of OS-agnostic ones. It is not a library developer
>> > role to promise an easy life to maintainers of any of the PMs/PDMs.
>> > It would be a sisyphean task.
>>
>> That's not very considerate.
>>
>> If GEOS becomes too painful to maintain, I'll remove it from Debian to
>> keep my sanity, and leave it up to users to build it themselves and
>> integrate it with the other packages.
>>
>> If that requires the removal of other packages that require GEOS, so be
>> it. That just reduced the number of packages I have to maintain. It's
>> not in the best interest of our users, but fuck them too, right?
>>
>> Kind Regards,
>>
>> Bas
>>
>> --
>>  GPG Key ID: 4096R/6750F10AE88D4AF1
>> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>> ___
>> geos-devel mailing list
>> geos-devel@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel



-- 
--
http://schwehr.org
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[lnkansa]

NON PSC:
While I do appreciate the work of the library developers, I do support that
fact that C++ API is made available for the larger community. C++ is
enjoying Renaissance (11, 14, 17, 20) and attempts to "force" downstream
developers to use the the C-API rather decreases programmer productivity. A
good example would be the use of unique_ptr for resource management - it is
as good as it gets. Why not just use it as it is intended? After all, there
are always a thousand ways to compile a library with different compiler
switches. That is a beauty and also a pain - This is what partly defines
our DNA. Stable projects would always use CAPI knowing the consequences.
Anyone who opens up the hood should know what he is doing and if the person
shoots himself in the foot so be it. Those using C++ would have to compile
anyway. OSS projects that take such dependencies are the ones that should
pay the price and not the other way around. If their usage breaks your
packaged distro, they should pay the price of being dropped. After all
engineering is about choices. Please bring the C++ API back a first class
citizen.

On Fri, May 17, 2019 at 4:53 PM Sebastiaan Couwenberg 
wrote:

> On 5/17/19 4:43 PM, Mateusz Loskot wrote:
> > On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg 
> wrote:
> >> On 5/17/19 3:23 PM, Andrew Bell wrote:
> >>> Frequent, breaking API changes seem a problem. ABI changes seem more
> like a
> >>> small annoyance. I can understand how a stable ABI would be nice, but I
> >>> personally don't think it's more important than a good interface for
> >>> library users.
> >>
> >> And that's the difference in perspective between a developer and
> >> distribution packager.
> >
> > It is not my role of a library developer to make packaging easier.
> > There are many PMs and PDMs, OS-specific, distro-specific
> > as well as number of OS-agnostic ones. It is not a library developer
> > role to promise an easy life to maintainers of any of the PMs/PDMs.
> > It would be a sisyphean task.
>
> That's not very considerate.
>
> If GEOS becomes too painful to maintain, I'll remove it from Debian to
> keep my sanity, and leave it up to users to build it themselves and
> integrate it with the other packages.
>
> If that requires the removal of other packages that require GEOS, so be
> it. That just reduced the number of packages I have to maintain. It's
> not in the best interest of our users, but fuck them too, right?
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Sebastiaan Couwenberg]

On 5/17/19 4:43 PM, Mateusz Loskot wrote:
> On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg  
> wrote:
>> On 5/17/19 3:23 PM, Andrew Bell wrote:
>>> Frequent, breaking API changes seem a problem. ABI changes seem more like a
>>> small annoyance. I can understand how a stable ABI would be nice, but I
>>> personally don't think it's more important than a good interface for
>>> library users.
>>
>> And that's the difference in perspective between a developer and
>> distribution packager.
> 
> It is not my role of a library developer to make packaging easier.
> There are many PMs and PDMs, OS-specific, distro-specific
> as well as number of OS-agnostic ones. It is not a library developer
> role to promise an easy life to maintainers of any of the PMs/PDMs.
> It would be a sisyphean task.

That's not very considerate.

If GEOS becomes too painful to maintain, I'll remove it from Debian to
keep my sanity, and leave it up to users to build it themselves and
integrate it with the other packages.

If that requires the removal of other packages that require GEOS, so be
it. That just reduced the number of packages I have to maintain. It's
not in the best interest of our users, but fuck them too, right?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Mateusz Loskot]

On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg  wrote:
> On 5/17/19 3:23 PM, Andrew Bell wrote:
> > Frequent, breaking API changes seem a problem. ABI changes seem more like a
> > small annoyance. I can understand how a stable ABI would be nice, but I
> > personally don't think it's more important than a good interface for
> > library users.
>
> And that's the difference in perspective between a developer and
> distribution packager.

It is not my role of a library developer to make packaging easier.
There are many PMs and PDMs, OS-specific, distro-specific
as well as number of OS-agnostic ones. It is not a library developer
role to promise an easy life to maintainers of any of the PMs/PDMs.
It would be a sisyphean task.

Since day one, GEOS has been a C++ library.
Since version 2.2, GEOS offers C API.
Since version 3.6, things started shifting in a direction that transforms
the library, departing from the original concept.
It dents the trust inside the team (what else will get hastily broken?).

It's those who support the intrusive transformation should have forked
GEOS and make their way, not those who want to maintain GEOS
according to the original concept.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Paul Ramsey]

+1 from me

This change rolled through very quickly. We have survived perfectly
happily with our old policy of installing all the headers and letting
people shoot off exactly as many toes of their feet as they like.
Having a C++ library that doesn't let people build against it is a
little weird. I know packagers like to have only one copy of a system
library that never ever changes, but that's just not realistic. Rather
than packagers wagging the project dog, I would rather see packagers,
who now very much know about this issue, use some other approaches to
achieve the level of stability they desire. I'd think that, for apps
that are built against the C++ API, statically linking them to GEOS
would be a nice way to avoid getting locked into a particular system
version of GEOS.

This change is still intra-release, I see no particular problem with
rolling it back, and having 3.8 look very much like 3.7.

P.


On Thu, May 16, 2019 at 4:28 PM Mateusz Loskot  wrote:
>
> Dear All,
>
> I'd like propose to effectively revert the RFC 6:
>
> https://trac.osgeo.org/geos/wiki/RFC9
>
> I'll appreciate if the PSC members considered to review my proposal
> and arranged the voting.
>
> Although I've made my best to prepare the write short,
> clear and unambiguous proposal, I'll welcome your feedback.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

> On 5/17/19 3:23 PM, Andrew Bell wrote:
> > Frequent, breaking API changes seem a problem. ABI changes seem more
> > like a small annoyance. I can understand how a stable ABI would be
> > nice, but I personally don't think it's more important than a good
> > interface for library users.
> 
> And that's the difference in perspective between a developer and distribution
> packager.
> 
> Kind Regards,
> 
> Bas
> 
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
[Regina Obe] 
Exactly.  These days my sensitivities like more on the packaging side than the 
development side.
If GEOS was a fledgling project I would be fine with broadcasting yeh we have a 
public C++ API.

The thing is you can still use the C++API, we are just making it clear that you 
are on your own, which mloskot claims C++ developers know already.

Well guess what? the users/developers downstream of some project that depends 
on GEOS may not know that, and then they'll be screwed when we change the API.
So the notice lets them know they are trusting something they shouldn't if they 
try to use the C++ API directly.

Right now the C++ API I feel is more in flux than ever, so the last thing I 
want is people relying on it especially now while we are making major changes 
to it.
If you are building your pet C++ project that no one else is going to use, we 
are not stopping you from taking full advantage of the GEOS C++ API, but at 
your own risk.  If you expect package managers to package your software, then 
you gotta make it easier for us.

Thanks,
Regina





___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Sebastiaan Couwenberg]

On 5/17/19 3:23 PM, Andrew Bell wrote:
> Frequent, breaking API changes seem a problem. ABI changes seem more like a
> small annoyance. I can understand how a stable ABI would be nice, but I
> personally don't think it's more important than a good interface for
> library users.

And that's the difference in perspective between a developer and
distribution packager.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Sebastiaan Couwenberg]

On 5/17/19 2:21 PM, Andrew Bell wrote:
> But this seems like a choice for library users. From a packaging
> perspective, why isn't the issue one of API rather than binary
> compatibility?

Both API and ABI compatibility and an issue. API breaks require the
projects to adapt their code which takes time, ABI breaks require
distros to rebuild the packages. ABI breaks without API breaks suck, and
C++ has a tendency for that which C doesn't have. Yay for stable C symbols.

> Are you not rebuilding packages?

Obviously we are. And that's the problem, new GEOS releases tend to
cause build failures for the projects that rely on the C++ API.

Everything that relies on the stable C API doesn't need to be rebuilt
for new GEOS releases.

> On Fri, May 17, 2019, 6:30 AM Sebastiaan Couwenberg 
> wrote:
> 
>> On 5/17/19 1:14 PM, Andrew Bell wrote:
>>> Why is this? There are many libraries that have C++ interfaces.
>>
>> Which also have difficulty providing a stable ABI. One that doesn't
>> change the symbols it exports with the new compiler releases, etc.
>>
>> Having a stable C ABI is a major plus for any project that uses C++ in
>> its codebase, it makes transitions to new releases much easier. A core
>> library like GEOS have many projects that require it, some are actively
>> maintained and implement changes quicky, others don't. And these make
>> life suck for distributions where all the projects need to be integrated
>> to work with the same version of GEOS.
>>
>>> On Thu, May 16, 2019, 11:37 PM Sebastiaan Couwenberg >>
>>> wrote:
>>>
 On 5/16/19 11:28 PM, Mateusz Loskot wrote:
> I'd like propose to effectively revert the RFC 6:
>
> https://trac.osgeo.org/geos/wiki/RFC9

 Please don't. We'll get more projects like OSSIM that break with new
 GEOS releases, this causes significant delays before the new release can
 be included in distributions where lots of projects depend on GEOS
 (which all need to build with the new release).
>>
>> Kind Regards,
>>
>> Bas
>>
>> --
>>  GPG Key ID: 4096R/6750F10AE88D4AF1
>> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>> ___
>> geos-devel mailing list
>> geos-devel@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> 
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
> 


-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Andrew Bell]

But this seems like a choice for library users. From a packaging
perspective, why isn't the issue one of API rather than binary
compatibility? Are you not rebuilding packages?

On Fri, May 17, 2019, 6:30 AM Sebastiaan Couwenberg 
wrote:

> On 5/17/19 1:14 PM, Andrew Bell wrote:
> > Why is this? There are many libraries that have C++ interfaces.
>
> Which also have difficulty providing a stable ABI. One that doesn't
> change the symbols it exports with the new compiler releases, etc.
>
> Having a stable C ABI is a major plus for any project that uses C++ in
> its codebase, it makes transitions to new releases much easier. A core
> library like GEOS have many projects that require it, some are actively
> maintained and implement changes quicky, others don't. And these make
> life suck for distributions where all the projects need to be integrated
> to work with the same version of GEOS.
>
> > On Thu, May 16, 2019, 11:37 PM Sebastiaan Couwenberg  >
> > wrote:
> >
> >> On 5/16/19 11:28 PM, Mateusz Loskot wrote:
> >>> I'd like propose to effectively revert the RFC 6:
> >>>
> >>> https://trac.osgeo.org/geos/wiki/RFC9
> >>
> >> Please don't. We'll get more projects like OSSIM that break with new
> >> GEOS releases, this causes significant delays before the new release can
> >> be included in distributions where lots of projects depend on GEOS
> >> (which all need to build with the new release).
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Sebastiaan Couwenberg]

On 5/17/19 1:14 PM, Andrew Bell wrote:
> Why is this? There are many libraries that have C++ interfaces.

Which also have difficulty providing a stable ABI. One that doesn't
change the symbols it exports with the new compiler releases, etc.

Having a stable C ABI is a major plus for any project that uses C++ in
its codebase, it makes transitions to new releases much easier. A core
library like GEOS have many projects that require it, some are actively
maintained and implement changes quicky, others don't. And these make
life suck for distributions where all the projects need to be integrated
to work with the same version of GEOS.

> On Thu, May 16, 2019, 11:37 PM Sebastiaan Couwenberg 
> wrote:
> 
>> On 5/16/19 11:28 PM, Mateusz Loskot wrote:
>>> I'd like propose to effectively revert the RFC 6:
>>>
>>> https://trac.osgeo.org/geos/wiki/RFC9
>>
>> Please don't. We'll get more projects like OSSIM that break with new
>> GEOS releases, this causes significant delays before the new release can
>> be included in distributions where lots of projects depend on GEOS
>> (which all need to build with the new release).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Howard Butler]

> On May 16, 2019, at 6:49 PM, Regina Obe  wrote:
> 
> -1
> 
> Not much has changed since we made this decision to make it non-public. In 
> fact ironically I feel like more people are using GEOS than before.
> I was hoping removing the C++ public would scare more people away so we could 
> do some major rework :).
> 
> I'd like us to be able to guarantee some bit of ABI stability before we go 
> taking this restriction off.
> 
> NO ONE READS READMES, they rely on at least some light punches :)

The decision to remove the C++ API from GEOS questions we as the GEOS PSC are 
trustworthy stewards of the library and shows disrespects for our users' 
investment and use of it. To have snapped our fingers and removed something 
that we know people were using because a few laggard packages in one packaging 
system caused some churn was a reckless overreaction. 

I vetoe'd the original proposal at the time because of the proposal to only 
allow installation of the C++ headers via opt-in. I regret not having holding 
firm on my veto, and I suppose it is now too late for us to maneuver around 
each other on the Prairie of Prax.

By the way, RFC6 is listed as Not Passed https://trac.osgeo.org/geos/wiki/RFC6 
 without a record of the vote, but the 
software was implemented as you proposed anyway. 

Howard___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Andrew Bell]

Why is this? There are many libraries that have C++ interfaces.

On Thu, May 16, 2019, 11:37 PM Sebastiaan Couwenberg 
wrote:

> On 5/16/19 11:28 PM, Mateusz Loskot wrote:
> > I'd like propose to effectively revert the RFC 6:
> >
> > https://trac.osgeo.org/geos/wiki/RFC9
>
> Please don't. We'll get more projects like OSSIM that break with new
> GEOS releases, this causes significant delays before the new release can
> be included in distributions where lots of projects depend on GEOS
> (which all need to build with the new release).
>
> Kind Regards,
>
> Bas
>
> --
>  GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Sebastiaan Couwenberg]

On 5/16/19 11:28 PM, Mateusz Loskot wrote:
> I'd like propose to effectively revert the RFC 6:
> 
> https://trac.osgeo.org/geos/wiki/RFC9

Please don't. We'll get more projects like OSSIM that break with new
GEOS releases, this causes significant delays before the new release can
be included in distributions where lots of projects depend on GEOS
(which all need to build with the new release).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Regina Obe]

-1

Not much has changed since we made this decision to make it non-public. In fact 
ironically I feel like more people are using GEOS than before.
I was hoping removing the C++ public would scare more people away so we could 
do some major rework :).

I'd like us to be able to guarantee some bit of ABI stability before we go 
taking this restriction off.

NO ONE READS READMES, they rely on at least some light punches :)




> -Original Message-
> From: geos-devel [mailto:geos-devel-boun...@lists.osgeo.org] On Behalf Of
> Mateusz Loskot
> Sent: Thursday, May 16, 2019 5:28 PM
> To: geos-devel@lists.osgeo.org
> Subject: [geos-devel] RFC 9: Restore C++ API as public API
> 
> Dear All,
> 
> I'd like propose to effectively revert the RFC 6:
> 
> https://trac.osgeo.org/geos/wiki/RFC9
> 
> I'll appreciate if the PSC members considered to review my proposal and
> arranged the voting.
> 
> Although I've made my best to prepare the write short, clear and
> unambiguous proposal, I'll welcome your feedback.
> 
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel

___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel

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

[Kurt Schwehr]

+1 from a non-PSC person

On Thu, May 16, 2019 at 2:28 PM Mateusz Loskot  wrote:

> Dear All,
>
> I'd like propose to effectively revert the RFC 6:
>
> https://trac.osgeo.org/geos/wiki/RFC9
>
> I'll appreciate if the PSC members considered to review my proposal
> and arranged the voting.
>
> Although I've made my best to prepare the write short,
> clear and unambiguous proposal, I'll welcome your feedback.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> ___
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel



-- 
--
http://schwehr.org
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel