Subject: Re: [boost] GGL Extensions
From: Christian Henning (chhenning_at_[hidden])
Date: 2009-11-11 11:03:41
>> I'm not sure that the extensions proposal worked very well for GIL.
>> I'm not sure why.
> This is interesting. Perhaps GIL maintainers could share their opinion?
I have been developing some gil extensions myself and I find it very
straightforward. I also try to keep all gil extension in my repository
( see here: http://code.google.com/p/gil-contributions/ ). Quite a few
people have been contributed when gil was released but since then
interest went downwards. My opinion is that gil might be to hard to
understand and there is a lot of basic functionality missing.
Enough of rambling. FWIW, I can see two different types of extensions
for gil. First is to add new functionality to the existing core of
gil, like adding new pixel types or image types. And second is to
develop what's completely missing in gil, all together. For instance I
developed a basic OpenCV extension.
Let's consider the first type since it intervenes with gil source code
much more closely. Have a look at:
Here, I'm adding a new pixel type. It looks very straighforward but
it's also very rigid, for a good reason. GIL relies a lot on
metaprogramming and though each pixel and it's components ( channels )
must fit right in. Also, default color converters have to be added to
keep certain gil-supplied algorithms working. If something isn't
working the user will get miles of error messages. Too bad concepts
aren't part of c++, yet.
Here another example for adding a new image type to gil:
To have a healthy developer base one has to the lead and do the
necessary maintenance. For a user to have to go to two places to get
the wanted functionality is quite a show stopper. First to go to boost
for ggl and then to ggl extension site might be to much for most
people. The solution is have boost excepting extensions a lost faster
than libraries which can take months if not even years. Maybe boost
can do something about it?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk