RFC 9: Restore C++ API as public API

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC 9: Restore C++ API as public API

Mateusz Loskot
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Kurt Schwehr-2
+1 from a non-PSC person

On Thu, May 16, 2019 at 2:28 PM Mateusz Loskot <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel


--

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Regina Obe
In reply to this post by Mateusz Loskot
-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:[hidden email]] On Behalf Of
> Mateusz Loskot
> Sent: Thursday, May 16, 2019 5:28 PM
> To: [hidden email]
> 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Sebastiaan Couwenberg
In reply to this post by Mateusz Loskot
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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

andrew.bell.ia@gmail.com
Why is this? There are many libraries that have C++ interfaces.

On Thu, May 16, 2019, 11:37 PM Sebastiaan Couwenberg <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Howard Butler-3
In reply to this post by Regina Obe


On May 16, 2019, at 6:49 PM, Regina Obe <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Sebastiaan Couwenberg
In reply to this post by andrew.bell.ia@gmail.com
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 <[hidden email]>
> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

andrew.bell.ia@gmail.com
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 <[hidden email]> 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 <[hidden email]>
> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>
> 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 <[hidden email]
>>>
>>> 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
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

andrew.bell.ia@gmail.com


On Fri, May 17, 2019, 7:56 AM Sebastiaan Couwenberg <[hidden email]> wrote:
On 5/17/19 2:21 PM, Andrew Bell wrote:

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

This implies that "stable" is the
important bit. This is, IMO, a design issue, rather than one of a language choice, generally speaking.

For people writing C++ there is real value in a stable and well-designed C++ library interface that simplifies development and potentially reduces bugs. This is an important consideration. For example, dealing with memory ownership for some C libraries can be trouble and can make for convoluted code.

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.

> On Fri, May 17, 2019, 6:30 AM Sebastiaan Couwenberg <[hidden email]>
> 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 <[hidden email]
>>>
>>> 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
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

andrew.bell.ia@gmail.com
On Fri, May 17, 2019, 8:53 AM Regina Obe <[hidden email]> 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.
>
> 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...

How so? Shared libraries are versioned. If you're not rebuilding against a new API, the soname should guarantee usability.

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.

Why are you doing this? If you want to significantly change the interface, why not make a new one in a new namespace, for example? This would preserve backward compatibility for existing users.

This really strikes me as a design issue, rather than one of packaging.

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Paul Ramsey
In reply to this post by Mateusz Loskot
+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 <[hidden email]> 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
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Mateusz Loskot
In reply to this post by Sebastiaan Couwenberg
On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
On 5/17/19 4:43 PM, Mateusz Loskot wrote:
> On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: RFC 9: Restore C++ API as public API

Kurt Schwehr-2
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 <[hidden email]> 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 <[hidden email]> wrote:
On 5/17/19 4:43 PM, Mateusz Loskot wrote:
> On Fri, 17 May 2019 at 08:36, Sebastiaan Couwenberg <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel


--

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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, [hidden email]
(Sent from mobile)


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


On Fri, 17 May 2019, 14:13 Regina Obe, <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-development


On Fri, 17 May 2019, 14:13 Regina Obe, <[hidden email]> 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
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel

_______________________________________________
geos-devel mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/geos-devel
12