C API

[bjornharrtell]

Would be useful for C only projects, like PostGIS.

[joto]

C is out of scope for us.

[springmeyer]

@bjornharrtell - can you say more about what would be helpful for allowing PostGIS to depend on protozero? Is a C API really a blocker? Couldn't PostGIS simply wrap the calls to protozero itself as needed?

I agree with @joto that providing a C API is out of scope. But I'm interested to learn more about why you think it would be useful.

[bjornharrtell]

My C/C++ is a bit rusty so I might not be technically correct here, but as I see it wrapping the calls is a C API? Of course, maintaining a public and generic C API is probably a lot harder than making a specific wrapper for use in PostGIS protobuf related functions so if that is the main concern I understand.

I think for PostGIS it's simply an issue of not introducing any more complexity (i.e C++ compiler dependency and tooling) to an already too complex build tool chain (some of it due to technical debt). Not necessarily a blocker but might require significant effort to convince the core team. A prior example is that PostGIS did have a C++ dependency on the GEOS library but a C API was introduced because it caused too much maintenance pain on the PostGIS side.

[springmeyer]

Thanks for the further thoughts @bjornharrtell. Before I respond to individual notes I'll make clear that protozero is a very specialized project and may not be appropriate for postgis:

• It is header only. That means there is nothing to compile on its own. When you compile and link your code that depends on protozero, that is when protozero is compiled. So you need a C++ compiler.
• The C++ compiler also must be modern and support the -std=c++11 flag

My C/C++ is a bit rusty so I might not be technically correct here, but as I see it wrapping the calls is a C API?

My understanding is that a "C API" is an interface that exposes only C types and can be linked without a C++ compiler. Wrapping protozero, because it is C++ headers, would need a C++ compiler. So, to truly make a C API you'd need to wrap protozero calls and provide a pure C interface to access them. Neither are goals of the protozero project.

Of course, maintaining a public and generic C API is probably a lot harder than making a specific wrapper for use in PostGIS protobuf related functions so if that is the main concern I understand.

Yes, my feeling too.

I think for PostGIS it's simply an issue of not introducing any more complexity (i.e C++ compiler dependency and tooling) to an already too complex build tool chain (some of it due to technical debt).

Right, that sounds familiar. I recall how GDAL and GEOS both provide C APIs that postgis prefers to use. Building those dependencies requires a C++ compiler, but linking them does not, since they provide a C API.

Not necessarily a blocker but might require significant effort to convince the core team. A prior example is that PostGIS did have a C++ dependency on the GEOS library but a C API was introduced because it caused too much maintenance pain on the PostGIS side.

I gather that was because it was easier historically to maintain compatibility with multiple GEOS versions via the more simple C interface rather than the C++ interface.

It sounds to me like if you are trying to figure out what protobuf parsing to use in PostGIS you would be better served by using a project written in C like https://github.com/protobuf-c/protobuf-c.

[bjornharrtell]

Agreed on all points. The current protobuf related code in PostGIS already uses protobuf-c.