[postgis-devel] Re-organising the PostGIS codebase - to liblwgeom or not liblwgeom?

[Mark Cave-Ayland]

Paul Ramsey wrote:
> My take:
> 
> 1- PGXS, good, follow the big fish...

Cool :)

> 2- liblwgeom, unsure, leaning negative
> 
> Some of the questions I have seen on the list about the wrappering of
> types, and my own reading of functions has made me less than enamoured
> of the abstraction layer.  The trouble is that is violates YAGNI (my
> new personal religion). No one has asked us for this, no one is using
> it *currently*, so why should we add complexity to our own code to
> support it?
> 
> If we want do so any separation of concerns, I would lean towards a
> very very simple geometry algorithm library in pure C, statically
> linked, for things like our length/distance/pip/area and other
> routines. Otherwise I would be on the side of doing away with the
> liblwpostgis separation.

My current view of the codebase is that the transformation between 
LWGEOM and PG_LWGEOM (or SERIALIZED_FORM(geom)) is not particularly 
well-defined in many cases. In particular, there is much confusion in 
the function naming convention for handling operations with each one. 
Having an API in place would almost certainly help resolve this issue 
and help untangle things from a maintenance point of view.

 From my initial experiments, one of the first places to benefit from 
this would be the parser, as there are so many different routines all 
over the code :(  It would be good to sort this out, so that following 
this section of the code is a lot easier to maintain.

I think a good starting point would be to link the LWGEOM routines into 
a separate static library, and then link that library into the final 
PostgreSQL library. So in other words, the abstraction would remain 
internal, but mainly for the purposes of encouraging code re-use within 
the project.

> 3- branch trunk or branch development
> 
> I think we can branch trunk to 1.3.x and let development march on
> trunk. That means we're committing to get a bunch of big changes
> through and stabilized before we get to 1.4... hope we're OK with
> that.
> 
> I lean towards the above because that way we can all watch/help as you
> start moving things around.

I think that will be the best way, given the large amount of changes 
planned. The plan would be to commit the first set of changes that will 
actually compile (i.e. re-do the autoconf and Makefile to use PGXS), and 
then slowly make the other changes. In other words, commit little but often.



ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063