[Liblas-devel] ABI/API stability (was Indexing for point clouds)

[Howard Butler]

On Apr 22, 2009, at 8:08 AM, Mateusz Loskot wrote:

> Hamish wrote:
>> Also, I've been meaning to send a note about the C/C++ ABI stability
>> issues. There was a thread on the DebianGIS list about GDAL's C/C++
>> ABI and who should link to what. The result was that the C ABI was  
>> heavily favoured for external apps to use even though internally GDAL
>> is written in C++. Maybe it is just GDAL specific -- you can read  
>> Frank's comments at the following link, possibly it gives you some  
>> ideas for how to handle this in libLAS.
>> http://thread.gmane.org/gmane.comp.gis.grass.pkg.general/1230/focus=1286

>>
> Personally, I really don't like this approach because it causes a  
> lot of
> problems on the level of development (not use) of software.
> The core (in GDAL, libLAS, others) is written in C++ but higher
> priority is given to C API. Whenever you want to update the core
> (written in C++), you have to check if it breaks anything in the C  
> API.
> Perhaps GDAL C solves problems for users, but it makes more troubles  
> to
> developers and maintenance by slowing down improving and
> evolving the project, not to mention *confusing* users - the proof is
> what we can observe - people use GDAL C or C++ API or even mix them
> together!
>
> Shortly, for me this approach is like a cyclic dependency
> which is hard to solve.
>
> I understand the ABI problems and that users like to have things  
> written
> once and use forever, but at the same time I'm very sure this approach
> is no longer valid today.
>
> Instead, it's better to promise compatibility of C++ API within major
> milestones but to not to promise it between major versions.
> Just like it is done in Boost C++ Libraries - and nobody complains  
> that
> 1.38 has tons of new API comparing to 1.34.
>
> Or, just like it's done in GNOME, GTK, libxml and others - physically
> separate development of core and API wrapper and make the core higher
> priority but the wrapper following (slow, fast or very slow) what
> happens in the core. See GTK+ (C) and Gtkmm (C++).
>
> Regardless of my personal disappointment about the C++ vs C API in  
> GDAL,
> I'm not going to force any other approach in libLAS.

Hamish

Given that Mateusz and I are both GDAL developers and we have both  
suffered (and benefitted) under its maintenance structure for quite a  
while, we are looking for some kind of balance.  Right now, we are  
fairly closely following the GDAL model -- totally non-stable C++ API,  
boringly stable C API, and a Python API that follows the C API.  As  
Mateusz says, this introduces a number of maintenance headaches.   
Specifically, it doesn't allow for much innovation because the pain of  
a simple change in the C++ API ripples throughout the software --  
meaning the incentive is either to change things very lightly or not  
change stuff at all.  This makes improvements that would be great  
leaps incredibly hard to do (think thread safety/threading support,  
various read buffering strategy implementations, etc).

As I suggested in <http://lists.osgeo.org/pipermail/liblas-devel/2009-April/000462.html 
 >, I think the solution is to separate the APIs so they are  
individual sub projects.  This would allow the innovation and boredom  
to coexist without each impacting each other so greatly ;) We weren't  
going to embark on this until we had some idea of the expectation and  
usages of the various APIs though.  Without anyone speaking up against  
it, we're just going to do it, however.

Howard