<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Thomas,
<div class=""><br class="">
</div>
<div class="">you said most of what I had in mind, so I’ll just add that almost all functions in the library today is part of the public API. Either through projects.h or proj_api.h. That doesn’t leave much room for refactoring in general. I recently touched
the gridshifting code, but had to stay within the boundaries of the current functions in order to not break the API. I could have come up with better implementations if I had been able to change things at a deeper level. The biggest offender is projects.h
which absolutely should be a private header.
<div class=""><br class="">
</div>
<div class="">Even,</div>
<div class=""><br class="">
</div>
<div class="">I think it is possible to make a compatibility layer as you suggest. Most of what is needed is in place already. I understand your reasoning, though I am not too keen on taking on this task myself. Your alternative plan sounds better to me, although
we would then introduce a breaking change at the 5.1.0 version, which kind of goes against the semantic versioning scheme that we ought to follow. It can easily be solved by changing your proposed error message to <span style="font-size: 9pt;" class="">I_AM_M_AWARE_PROJ_API_H_WILL_</span><wbr class="" style="font-size: 9pt;"><span style="font-size: 9pt;" class="">BE_REMOVED_IN_PROJ_6_0
and then release version 6 a year after version 5. It should also be added to projects.h.</span></div>
<div class=""><br class="">
</div>
<div class="">Anyway, I don’t want to restart the discussion we had a few months ago, I just wanted to take the temperature on this with the clear decision about going to version 5 in the next release.</div>
<div class=""><br class="">
</div>
<div class="">/Kristian</div>
<div class=""> </div>
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 13 Nov 2017, at 16:43, Thomas Knudsen <<a href="mailto:knudsen.thomas@gmail.com" class="">knudsen.thomas@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">Even, regarding simplification by elimination:
<div class=""><br class="">
</div>
<div class="">Obviously Kristian will want to answer this himself, but I would like to mention at least one thing (or perhaps rather aspect) that will buy us simplification by eliminating projects.h and proj_api.h:</div>
<div class=""><br class="">
</div>
<div class="">We would get rid of the type-punning-by-preprocessor-defs that destroyed Gerald's classic PROJ.4 core API, (pj_init, pj_fwd, pj_inv, and pj_free), by turning XY and LP into UV behind the back of the user, such that XY xy is no longer adressed
xy.x and xy.y, but xy.u and xy.v</div>
<div class=""><br class="">
</div>
<div class="">We would also get rid of the half baked namespacing-and-information-hiding-by-misleading-typedef, implemented by e.g.</div>
<div class="">
<div class="">typedef void *projPJ, and typedef void *projCtx, rather than by forward declarations.</div>
</div>
<div class=""><br class="">
</div>
<div class="">This kind of stuff has been hell to work around (see the text in the top of proj.h for rationale for the work). This is not said to belittle Frank's work, which has been of immense value for PROJ.4, and has kept it afloat and in constant evolution,
for more than 15 years: His work is admirable, but has, naturally, been focused on whatever (or whom-ever) paid the bills.</div>
<div class=""><br class="">
</div>
<div class="">This has given us support for vertical datums, support for NTv2, support for a "failrly accurate for the needs when it was introduced 15 years ago" interface function as pj_transform, which to a large degree succeeds in "giving the user what (s)he
wants without asking too many annoying geodetic questions".</div>
<div class=""><br class="">
</div>
<div class="">It has, however, also given us the, largely superfluous contexts, and the fileapi, which, apart form missing a fgetc- style function, also in general suffer from a feeling of "work made for hire" for a specific customer, using it for in house
stuff (only since it is largely unknown by search engines) - but now we have to maintain this stuff,without even knowing what the rationale behind was.</div>
<div class=""><br class="">
</div>
<div class="">So yes - we could certainly benefit from skipping projects.h and proj_api.h : It will buy us some simplifications - I'm just not sure that this is the right way to do things. More about this later.</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">2017-11-11 20:06 GMT+01:00 Even Rouault <span dir="ltr" class="">
<<a href="mailto:even.rouault@spatialys.com" target="_blank" class="">even.rouault@spatialys.com</a>></span>:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u class=""></u>
<div style="font-family:'Sans Serif';font-size:9pt;font-weight:400;font-style:normal" class="">
<span class="">
<div style="margin: 0px; text-indent: 0px;" class="">On samedi 11 novembre 2017 17:32:05 CET Kristian Evers wrote:</div>
<div style="margin: 0px; text-indent: 0px;" class="">> PROJ v. 5.0.0 is also good with me. It also brings us into "braking changes</div>
<div style="margin: 0px; text-indent: 0px;" class="">> territory". With this in mind I think we should consider only supporting</div>
<div style="margin: 0px; text-indent: 0px;" class="">> the new API in proj.h and dropping the other APIs. This will allow us to</div>
<div style="margin: 0px; text-indent: 0px;" class="">> simplify the code immensely.
</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
</span>
<div style="margin: 0px; text-indent: 0px;" class="">Can you sketch a bit what would be simplified in doing so ?</div>
<span class="">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">> At the moment we jump through a bunch of hoops</div>
<div style="margin: 0px; text-indent: 0px;" class="">> to keep backwards compatibility. We'd probably still do that for the next</div>
<div style="margin: 0px; text-indent: 0px;" class="">> release, but not having projects.h and proj_api.h as part of the public API</div>
<div style="margin: 0px; text-indent: 0px;" class="">> we can change things behind the scenes in future releases.</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
</span>
<div style="margin: 0px; text-indent: 0px;" class="">If I remember the analysis of Debian packages, while dropping projects.h would have a moderate impact, dropping proj_api.h would cause massive breakage. This would likely cause proj 5 to take months to years
before being available in distributions due to many packages not being ready for it (and the proj_api.h -> proj.h port is the kind of change that needs to be done by upstream projects. not a quick&dirty hack that the packager can do)</div>
<div style="margin: 0px; text-indent: 0px;" class="">Thus in this context of software distributions, applications that would be adapted to use the new API wouldn't be able to use it in practice for a long time. Worse, applications that would do the changes
to support proj >= 5 would still to have to support both proj < 5 and proj >= 5 in a transition period if they want their new releases to be packaged. To make their life easier by avoiding to have them to support both API, a proj 5 should be available as packaged
as fast as possible.</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">I'm wondering if there wouldn't be a way of having a proj_api.c compatibiliy layer that would use the new API behind the scene ? The projPJ struct could be something different than the PJ one, for example
just storing the text. And when doing pj_transform() you would build a pipeline from the src and dest projPJ. Things like that. I believe the cost of creating this compatibility layer (assuming this is possible) would be worth it</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">Or alternate plan :</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">- for proj 5.0, add at top of proj_api.h</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">#ifndef I_AM_M_AWARE_PROJ_API_H_WILL_<wbr class="">BE_REMOVED_IN_PROJ_5_1</div>
<div style="margin: 0px; text-indent: 0px;" class="">#error "proj_api.h will be removed in proj 5.1. You can still use it for now by defining I_AM_AWARE_PROJ_API_H_WILL_BE_<wbr class="">REMOVED_IN_PROJ_5_1, but you should strongly consider using proj.h now"</div>
<div style="margin: 0px; text-indent: 0px;" class="">#endif</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">Perhaps do the same for projects.h, if we really want proj 5 to be a no-brainer for packagers</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">- for proj 5.1, remove proj_api.h (and projects.h)</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">Benefits:</div>
<div style="margin: 0px; text-indent: 0px;" class="">* this would make proj 5 easy to be packaged, by avoiding a flag day</div>
<div style="margin: 0px; text-indent: 0px;" class="">* applications would be clearly warned they have to do something, and have time to do the changes</div>
<div style="margin: 0px; text-indent: 0px;" class="">* after proj 5.0 release, proj master could benefit from the needed cleanups.</div>
<span class="">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">Even</div>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px" class="">
</p>
<div style="margin: 0px; text-indent: 0px;" class="">-- </div>
<div style="margin: 0px; text-indent: 0px;" class="">Spatialys - Geospatial professional services</div>
<div style="margin: 0px; text-indent: 0px;" class=""><a href="http://www.spatialys.com/" target="_blank" class="">http://www.spatialys.com</a></div>
</span></div>
<br class="">
______________________________<wbr class="">_________________<br class="">
Proj mailing list<br class="">
<a href="mailto:Proj@lists.maptools.org" class="">Proj@lists.maptools.org</a><br class="">
<a href="http://lists.maptools.org/mailman/listinfo/proj" rel="noreferrer" target="_blank" class="">http://lists.maptools.org/<wbr class="">mailman/listinfo/proj</a><br class="">
</blockquote>
</div>
<br class="">
</div>
_______________________________________________<br class="">
Proj mailing list<br class="">
<a href="mailto:Proj@lists.maptools.org" class="">Proj@lists.maptools.org</a><br class="">
http://lists.maptools.org/mailman/listinfo/proj</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>