[postgis-devel] A letter to the Postgis Developers and Packagers

[Paragon Corporation]

Hello Andrea and Sandro,

I'm very appreciative of Tuscany Region's contributions to PostGIS.  As a packager maintainer and PostGIS developer, the whole lilblwgeom versioning has caused me some grief.
Largely I've worked that out on my own so it's just water under the bridge and no permanent harm done.

I would like the Topology C stuff to stay rather than being reverted back to plpgsql, even if it means we have to pay Sandro to copy liblwgeom bits from some other repo into PostGIS for updates.

1) I wasn't so bothered with liblwgeom having a life of it's own, but still within the PostGIS codebase if it was just SpatiaLite using it from PostGIS.  However now that Grass, QGIS etc are using it,
I feel things are moving too fast and will jeopardize both the future of PostGIS and the use of liblwgeom by others, unless we slow the pace down a bit.

2) Now that SFCGAL is becoming more commonly deployed, a PostGIS built with liblwgeom support means, a liblwgeom that has SFCGAL and CGAL dependencies. For other projects using liblwgeom (and not caring about PostGIS)
This extra dependency would not be a welcome addition.  Hell it wasn't welcome to me when my raster2pgsql, shp2pgsql, pgsql2shp, shp2pgsql-gui suddenly had SFCGAL/CGAL dependencies when they don't currently use any of those features.
So I had to revert back to staic compiling to get rid of the dependency.

3) Personally I don't feel that liblwgeom is mature enough as a stand-alone library to be shared by anyone without explicit caution that it's volatile and others jumping on board should be good swimmers.

4) As to whether liblwgeom gets forked for SpatiaLite use and others, I'm torn.  Yes the whole threading need and that SpatiaLite needs to release more frequently than PostGIS needs one, would suggest it just get forked and we part ways.
Though with PostgreSQL 9.6 coming soon and the whole parallel query thing coming in, I'm not sure if that may change our need for threading.

5) There is a danger that liblwgeom split from PostGIS would mean they go on their separate lives never to join again.  But I look at projects like MySQL, MariaDb, Percona and they seem to do more or less fine forking each and rejoining each other all the time.

If we could have an option so that PostGIS has it's own version of liblwgeom with a versioning scheme that matches the rest of PostGIS, with an optional switch to spit out another baby with it's own versioning that others can use, then the two can coexist using the same code base
And that code base be PostGIS.

I'm not sure how easy that is to do though.

That probably doesn't help Debian folks all that much except that liblwgeom so names won't change with each new micro release of PostGIS, but they'd still have to maintain 2 for largely identical libraries.

Thanks,
Regina


-----Original Message-----
From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Sandro Santilli
Sent: Monday, October 19, 2015 11:23 AM
To: Andrea Peri <aperi2007 at gmail.com>
Cc: postgis-devel at lists.osgeo.org
Subject: Re: [postgis-devel] A letter to the Postgis Developers and Packagers

Hello Andrea,

On Sun, Oct 18, 2015 at 08:52:14PM +0200, Andrea Peri wrote:

> We thought that the substitution of the PostGIS Topology functions 
> from plpgsql in C would not cause any problems to users, offering 
> instead performance improvements. But during its testing in 
> Spatialite, we realized that the library required several further refirements in its API.
> 
> This has created a situation of embarrassment that caused the break of 
> the new liblwgeom API just in the same day it was released along with 
> the new 2.2.0 version of PostGIS.

For the record, I think the liblwgeom API breakage was really not a big deal, especially as what broke was the new topological API, which is really only used by PostGIS itself (beside the ongoing Spatialite development).

> We apologize for causing, with our interventions in liblwgeom, the 
> release within PostGIS of a topological library that is not yet 
> complete and which definitely needs several revisions and other changes to the API.

I don't think you can be blamed, the modifications entered the PostGIS code base under my own responsibility so if someone feels it was an error to introduce such change, the fault is all on myself.

Personally, I don't see any damage introduced with those changes.
Yes, there's been a performance regression, but those kind of things tend to happen, and we've a fix for it already committed.

> Beeing in need of a more rapid test and release cycle for the topology 
> library, and with the aim to create a library which is compatible with 
> both PostGIS and Spatialite, we have identified as the best solution 
> to carry out the development, test and release activities in a 
> separate project. This choice also allows us to write the library with 
> a thread-safe model, which is not needed by PostGIS.

Both adding thread-safety to the library and having a faster release cycle are surely good reasons to have a separate package for the new library.

I've been hoping we could directly work at making liblwgeom itself turn into such an external library, but I understand the evaluated risk for increased cost of such a move makes other PSC members prefer not to do that.

Note I do not think the fundings spent on liblwgeom integration were wasted, as that allowed us to immediately prove the appropriateness of the library API and its correctness against the existing PostGIS Topology testsuite, which was also improved in the past thanks to Tuscany Region funding. And moving the code elsewhere would now mostly be a matter of renaming the symbols.

> As we fear the liblwgeom-topo code might be too immature and prone to 
> API breakage, we offer to finance the recovery in PostGIS of the 
> previous plpgsql implementation of the Topology module.

I think the API breakage issue could be as well fixed by excluding the topological support from the published liblwgeom headers.

Having topology function implemented in C opens the door to further improvements that aren't easy with the plpgsql.

Not knowing in advance when the external library will be ready, I'd rather keep using the internal version until an alternative is available.

There's a fair amount of code in the C topology module that doesn't belong to the C topology library API (implementation of the callbacks required by the library). That code will still be useful for using the external library, shall it have a similar interface to the current one (as I belive is the case).

If anyone else from the PSC prefers a revert, please speak up.

> The new topological library of Tuscany Region will be deposited on a 
> distinct GIT repository, with an open license similar to that of 
> liblwgeom and of course we will be pleased and honored if in the 
> future, when it will be more robust and reliable, the Community of 
> PostGIS Developers and Packagers will decide to link it as a shared 
> library for the topological component functions.

I hope that'll be soon possible.
Thanks for your continued support to free software development!

--strk;
_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-devel