Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale

Subject: Re: [boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
From: Jose (jmalv04_at_[hidden])
Date: 2009-11-17 03:59:34

On Mon, Nov 16, 2009 at 9:19 PM, Simonson, Lucanus J
<lucanus.j.simonson_at_[hidden]> wrote:
> There were two primary issues the no votes pointed out.  One was performance, which it turns out was a red herring exactly as the review manager concluded.  The other was support for floating point.  The interfaces support floating point while the polygon clipping algorithm does not.  It is unreasonable to ask me to implement a 2nd algorithm equal in scale to the first, since that is what would be required to add floating point support.  Once I am able to call a good implementation of polygon intersection that is licensed under the boost license the 2nd objection will also be addressed.  I am hoping that GGL might one day contain that implementation, but right now it does not.

Hi Luc,

My point is at a higher level. When there are important library
contributions that overlap, like Barend and yours, then Boost has to
find a way to integrate both of them. As each library is from a
different application domain, each has its own strengths and
weaknesses. The issue here is about cooperation rather than
confrontation !

>> 2) The scope of GTL was changed before the review (see snippet 2 at
>> the end) but the review docs still mention a wider app focus (see
>> snippet 1 at the end). This confusion appeared when GTL was being
>> reviewed.
>
> There is no inconsistency there.  Polygons are used in GIS and fixed point booleans are used in GIS.

The issue is that Boost aims for generic libraries if possible, so the
fact that the scope changed means that the fit is different.
I think the good intentions of the reviewer were that the library has
good algorithms/implementations so lets have them in Boost.
But, from a broader viewpoint I think more coordination is necessary.

>> 4) The GGL library proposal, which had been iterating the design with
>> input from boost, in my opinion received an unfair treatment
>> in the way the schedule was managed.

> My library has actually been iterating the design with input from boost for longer than GGL.  I did it in a more low key way than Barend, but I did iterate three or four times with the boost community on design and implementation issues over a period of years.  What I think is unfair to GGL is that it was brought to review too soon.  There are a number of issues and features not yet implemented that I think would have been better addressed before a formal review rather than after.  Personally I think this should have been another preview rather than a review of GGL, that way we could provide feedback to Barend without people jumping to his defense and saying things are unfair.

I know you have received a lot of input from the reviewer (as
acknowledged in your boostcon paper) and the reviewer is interested in
your algorithms, as expressed in emails. My interest is in a library
that fits the different application domains well and it's great that
there are authors with experience in these different domains

regards
jose