Re: [boost] new library (space partitioning)

Subject: Re: [boost] new library (space partitioning)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2010-07-27 17:22:36

Simonson, Lucanus J wrote:
> Adam Wulkiewicz wrote:
>> By the way, how the process of incorporation of new library looks
>> like?
>> When the library is good for become a candidate? Where it should be
>> placed etc.?
>
> You have two options.  First, you can go through the entire review process described here: http://www.boost.org/development/submissions.html
> The process is long, expect it to take at least one year.  I am keenly interested in seeing quality libraries like this developed under free license.  My organization would use them and I get asked twice a year on average if my library has it and if not if it exists under free license elsewhere.  I volunteer to be your review manager if the quality of the library meets my expectations so that is one stumbling block that won't trip you up.  (Some worthy libraries have difficulty finding a review manager.)  However, such a review would be quite controversial because some people will have a strong opinion that you should choose the other option.
>
> The other option is to engage with the newly accepted Boost.Geometry library.  They have already some plans to provide a simple 2D space partitioning tree that exists already in non-boost ready form.  I don't know the status of their development on it because I don't monitor their list and they don't discuss it on the boost dev list.  They are quite busy finishing implmenting their library and getting it release ready in terms of documentation and meeting the post conditions of their review.  My understanding is that there is at least four or five developers active in the project, though most of the work is done by the primary developer.  Engaging with them wouldn't necessarily shorten the time it takes to get your code released as part of boost, but it would allow you to avoid a formal review and instead just have to satisfy them that your code is ready to become a part of their library.
>
> While I also have a geometric boost library about to be released as part of 1.44:
> https://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm
> I don't think you can add your containers as new features to my library because:
> 1. the community pretty much decided that Boost.Geometry is where such new development should go
> 2. it doesn't fit very well in my library, which is named Boost.Polygon.  I provide a coordinate, point and rectangle concepts that could serve your needs, but you need spherical coordinate space concept as well, which Boost.Geometry already has.
>
> That said I'm not opposed to people extending my library in general, quite the opposite.  I can report the the Google Summer of Code project I'm currently mentoring has succeeded in producing a robust and optimal voronoi diagram of points sweepline implementation as is working toward voronoi of line segments and, by extension, polygons.
>
> My advice to you is to talk to the Boost.Geometry people and find out what their schedule is for release of their library.  If you are satisfied with adding a schedule dependency on their work then you write your interfaces to depend on their corrdinate, point, rectangle, sphere and coordinate system concepts and go through whatever process they have for accepting extensions.  I think your code should go in the core and not an extension because it is generally useful for all geometry and even things that aren't commonly though of as geometry, like database indexing, but that will be for you to work out with them.  They have put some thought into making their concepts extensible to n-dimensions, so hopefully you can benefit from that design work.  In a way it would be a shame that they went to the effort and then not have that work used for your containers.

Thank you for detailed answer and a proposition to be my review manager.

I think that the library I'd like to develop don't fit in 
Boost.Geometry. The purposes of both are different. Space partitioning 
(in mathematical meaning), is a separate problem. Functionality like 
this may be used in library like Boost.Geometry but might be used with a 
large number of different libraries as well. As I see it, it should be a 
set of general, n-dimensional solutions. Therefore I think, that it 
should be a separate library.

I'd rather choose option number one (thank you again) but I'll wait a 
while for the feedback from the comunity.

Regards,
Adam