[geos-devel] Reducing GEOS API (was: Coordinate copy removal in ElevationMatrix)

strk at refractions.net strk at refractions.net
Sat Dec 10 13:03:57 EST 2005

On Fri, Dec 09, 2005 at 10:53:36AM -0800, Paul Ramsey wrote:
> Well, doing so makes it harder for geos to become an  
> "infrastructural", which can be maintained in isolation from the  
> projects that depend on it.  Imagine a geos RPM as part of a Linux  
> distribution for example.  If we break ABI at regular intervals we  
> force upgrades of not only geos but all other dependent programs as  
> well at the same time.

Yes, this is problem.

> That said, I agree.  It is still relatively "early days" for geos,  
> development-wise, and improved performance is quite an important  
> requirement, judging from the comment profile on this list.

I think we should work more on preventing future breaks rather
then on performance. If we make up a stable API/ABI we'll
be free to improve performance in the future without the
compatibility problems.

This is where the C-API interface came in, but I'm afraid
that would not be enough, as C++ applications will still
be able to link to the C++ library and access ALL of
the most intimate interfaces of GEOS trhough the huge
collection of header files installed.

Actual code usually just uses a few of these interfaces
(Geometry, CoordinateSequence and their factories), but
still there's nothing there to forbid wider uses
(apart from streamlined documentation).

A general solution could be obsoleting all of the
internal geos headers (what's under the INCLUDEDIR/geos/*)
and keep a single geos.h with the smallest interface
we intend to maintain stable. Note that in this case
we should replace old-installed headers with new ones,
or the old will keep floating around and nothing could
stop users from linking against dying interfaces.

Another possibility (very drastic) would be to completely
avoid installing a shared C++ library, providing its
functionalities by a statically linked C lib.

I'd like to see a change in this direction (API reduction)
in GEOS-3.0.0.
The 2.2 branch as started with this in mind (taking time
before shipping 3.0.0).

Comments highly welcome.


> P.
> On 9-Dec-05, at 9:49 AM, Charlie Savage wrote:
> >Note sure what others think, but I would strongly vote to change  
> >GEOS's API as needed to improve its performance.
> >
> >Charlie
> >
> >strk at refractions.net wrote:
> >>Oh, BTW, this is in the HEAD branch, and required another break in  
> >>the ABI. I'll never stress this too much: GEOS API is too wide to  
> >>allow for performance improvements and reducing it would open up  
> >>many speedup possibilities. --strk; On Thu, Dec 08, 2005 at  
> >>03:27:29PM +0100, strk at refractions.net wrote:
> >>>I removed another copy of CoordinateSequence in ElevationMatrix.  
> >>>This removes useless copies of all Coordinates in output.
> >>_______________________________________________ geos-devel mailing  
> >>list geos-devel at geos.refractions.net http://geos.refractions.net/ 
> >>mailman/listinfo/geos-devel
> >_______________________________________________
> >geos-devel mailing list
> >geos-devel at geos.refractions.net
> >http://geos.refractions.net/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel


 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII. 

More information about the geos-devel mailing list