Re: [boost] Boost.Geometry and extensions (was: GGL review (JTF))

Subject: Re: [boost] Boost.Geometry and extensions (was: GGL review (JTF))
From: Christian Henning (chhenning_at_[hidden])
Date: 2009-12-04 15:09:07

Hi there, I like to see this movement for extensions. What I find the
right way to be is to have a boost_extension trunk with all the bells
and whistles that the boost trunk has. Mainly, we need website, trac,
regression tests, review and release process. I guess this sounds
similar to the before proposed unstable branch. But here the scope is
for extensions only. Boost has given us a way on how to structure
things and we should just copy it.

Is it possible to have the hosting and testing done on the boost
servers? What do you think?

Thanks,
Christian

On Fri, Dec 4, 2009 at 2:29 PM, Barend Gehrels <barend_at_[hidden]> wrote:
>
> Jonathan Franklin wrote:
>
>>>> However, it is a shame that the library lacks a first-class spatial
>>>> index capability in it's present state (e.g. what is up for review). ...
>>>>
>>>
>>> It is available as an extension, the reasons for non-inclusion were:
>>> - we want to improve performance
>>> - we want to enhance the interface
>>>
>>
>> So will it be moved *into* the library-proper at some point, or will
>> it always remain an extension?
>>
>
> We have never clarified this point until now, and herewith we want to, in
> the broader context of extensions (more reviewers mentioned extensions).
>
> Theoretically, options for extensions are:
> 1) no review at all
> 2) review within osgeo.org/ggl
> 3) fast track review within Boost
> 4) formal review within Boost
>
> And, orthogonally:
> a) smaller functionality, built in the library (so, without being an
> extension first)
> b) functionality, moving from "extension" to "kernel"
> c) functionality, staying as an extension forever (included in Boost
> distribution)
> d) functionality, staying as an extension forever (not included in Boost
> distribution)
>
> Probably every Boost library contains things as a). Those can come without
> (formal) review, so 1) will do. Algorithms fitting in the design and adding
> similar functionality are (probably) accepted in all libraries.
>
> However, there are, and might be more, extensions which are larger and have
> their own design, at least partly. The spatial index is such an extension.
> Some extensions will be written by us (submitters of GGL), other extensions
> might be written by programmers from the Boost community or from the
> GGL-mailing-list.
>
> For larger parts, as extensions are, so for b) and c), we propose to first
> do a review within the GGL-mailing-list. If we from that list think that the
> quality is good enough and that it is useful for inclusion within Boost, we
> want to propose a fast track review within Boost. Boost formally has that
> fast track review process; it is not used a lot (afaik), but it makes sense
> to use it for extensions.
>
> Spatial indexes are an example of b), because they are developed as an
> extension, but algorithms within the kernel might profit from it. So they
> then have to be moved somewhere inside the kernel.
> Projections are probably an example of c). They will probably always be
> extensions, but because of the worldwide usage of projections within GIS
> applications, it might make sense to have them within Boost as well. But
> that is then for a fast track review process to decide, of course.
>
> There are more libraries having extensions within Boost. GIL is mentioned
> before and has extensions distributed within Boost (so maybe like our c) )
> and not distributed (maybe d), don't know) but mentioned in the
> documentation and examples. And I noticed that GIL.IO is on the review
> schedule. So our proposal above might be conform conventions and
> expectations.
>
>
> Regards, Barend
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>