[Proj] Coming releases of PROJ.4

[Kristian Evers]

Even,

> As far as I know in the FOSS ecosystem, projects.h use is very marginal, or accidental. The only occurence I've in mind is in the OGDI project that uses nad_init() in one place. But I wouldn't mind too much about OGDI...

Good, that makes it a bit easier. There might be users outside of FOSS and I think it is fair to give them some time to bring their things in order if/when we break stuff.


> I'm not completely sure but I think the main driver for the context system was to remove / deprecate use of pj_errno as a global error variable. errno is now attached to the context.

Yeah, I believe the idea was to make it thread-safe. Why regular errno is not used I can understand though.

> We should probably make sure it is in a clean enough way before releasing it to the world


I agree. I think we have time to get it in a reasonable state before august.

> I'm wondering: is there a reason for having a new proj.h ?


The idea was to produce a new clean API with more sensible types, better namespace, etc. It has been discussed earlier both here and on GitHub (for instance here https://github.com/OSGeo/proj.4/pull/388)


 > On the other hand, having the new header and removing the old one will be an obvious way of signaling "eh, breaking changes have occured !" :-)



That was exactly what I had in mind! Along with a giant leap forward in version number it should raise all the flags of people using PROJ.4.

It was also why I suggested to keep a maintenance version based on 4.9.4 for a few years. So developers have time to absorb the changes in their own time.



> Actually one of the point of having a dedicatd proj.h would be to make sure that people don't accidentally use old API that will be removed. But I see that proj.h includes proj_api.h, so this risk still exists. Why proj.h couldn't avoid the proj_api.h depedency ?

I think it should be possible to remove the dependency of proj_api.h in proj.h. Perhaps by putting the parts that are dependant on proj_api.h in a proj_internal.h as suggested in your GitHub issue?

Kristian

Fra: Even Rouault [mailto:even.rouault at spatialys.com]
Sendt: 22. juni 2017 18:48
Til: proj at lists.maptools.org
Cc: Kristian Evers
Emne: Re: [Proj] Coming releases of PROJ.4


Kristian,



> The projects.h interface has a long history and exposes

> most of the inner workings of PROJ.4.



As far as I know in the FOSS ecosystem, projects.h use is very marginal, or accidental. The only occurence I've in mind is in the OGDI project that uses nad_init() in one place. But I wouldn't mind too much about OGDI...



> That is also why the

> proj_api.h interface exists. It was created in an effort of simplifying

> things and making a more modern API. That was now roughly 15 years ago, and

> On top of that it has some unfortunate

> design choices, for instance the context-system which is rather hard to

> work with and comprehend. Unfortunately it is also completely undocumented

> and the original ideas behind it seem to be lost.



I'm not completely sure but I think the main driver for the context system was to remove / deprecate use of pj_errno as a global error variable. errno is now attached to the context.



While just reviewing proj.h, I had a few questions/observations :

https://github.com/OSGeo/proj.4/issues/529 (I see you've began to answer to some questions while I was still editing it ;-))

We should probably make sure it is in a clean enough way before releasing it to the world



>

> PROJ.4 also has three different build-systems: Autotools, nmake and CMake.

> Autotools is the authoritative build-system which the other two try to

> mimic as best as possible. Nmake was introduced in order to build PROJ.4 on

> Windows and lately CMake has also been introduced as there was a demand for

> it.

>

> Due to the above I suggest that we focus our efforts entirely on the proj.h

> API and CMake from the next release and onwards.



Adoption of the new API and deprecation of proj_api.h will show greater resistance than dropping autoconf/nmake.



I'm wondering: is there a reason for having a new proj.h ? (we perhaps discussed that, but I already forgot) Imagine that I want to write code that is compatible of old and new proj versions (I'm pretty sure that a number of proj users will have to do that at some point). It could be convenient to still include proj_api.h and depending on the value of PJ_VERSION decide which API are available. Whereas if you have a new header, that make you also change your autoconf/cmake logic detection of proj4.



In the transition period, proj_api.h could have two sections : a section with the new API and with the ancient API clearly separated. At some point ancient API would be removed.



On the other hand, having the new header and removing the old one will be an obvious way of signaling "eh, breaking changes have occured !" :-)



Actually one of the point of having a dedicatd proj.h would be to make sure that people don't accidentally use old API that will be removed. But I see that proj.h includes proj_api.h, so this risk still exists. Why proj.h couldn't avoid the proj_api.h depedency ?



Even



--

Spatialys - Geospatial professional services

http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170622/42a00a9e/attachment.htm