GGL Extensions

[Tom Brinkman-2]

>> The GGL team proposes an extension model, very similar to what is used by GIL.

I'm not sure that the extensions proposal worked very well for GIL.
I'm not sure why.

Probably it was too ambitious.

Initially, just try encourage a small group of interested developers to work
with you on extensions.  When that number becomes too large, than start thinking
about a more formalized system.

If people see that there are a couple of
really cool extensions that were intergrated, it might
just encourage others to add extensions as well.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Mateusz Loskot]

Tom Brinkman wrote:
>>> The GGL team proposes an extension model, very similar to what is
>>> used by GIL.
>
> 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?

> Probably it was too ambitious.

I've started to lurk around GIL extensions fairly recently,
so I'm not able to judge.

> Initially, just try encourage a small group of interested developers
> to work with you on extensions.  When that number becomes too large,
> than start thinking about a more formalized system.
>
> If people see that there are a couple of really cool extensions that
> were intergrated, it might just encourage others to add extensions as
> well.

Good points.

Perhaps, in future, it would make sense to maintain two sets of extensions:
- internal or built-in tools specific to various domains
but mature enough to have them included as part of the library
- external - sort of incubator, place for more exotic tools,
experiments, etc.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Kai Schroeder-3]

I always wonder why the matlab central repository works so well. They
somehow manage to attract uploaders and got the level of complexity of
individual packages right. You can enter the name of an algorithm you need
and you get a package which contains exactly that algorithm with an example
attached( sometimes you also get toolboxes / libs, but single algorithms are
fully accepted). Users can rate and comment the packages which is a useful
guide when you look for something. Something like that would be nice for the
boost vault. An automatically generated page for each upload where users can
discuss and rate the contents.

Best regards,
Kai Schröder



On Wed, Nov 11, 2009 at 12:54 AM, Mateusz Loskot <mateusz@...> wrote:

> Tom Brinkman wrote:
> >>> The GGL team proposes an extension model, very similar to what is
> >>> used by GIL.
> >
> > 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?
>
> > Probably it was too ambitious.
>
> I've started to lurk around GIL extensions fairly recently,
> so I'm not able to judge.
>
> > Initially, just try encourage a small group of interested developers
> > to work with you on extensions.  When that number becomes too large,
> > than start thinking about a more formalized system.
> >
> > If people see that there are a couple of really cool extensions that
> > were intergrated, it might just encourage others to add extensions as
> > well.
>
> Good points.
>
> Perhaps, in future, it would make sense to maintain two sets of extensions:
> - internal or built-in tools specific to various domains
> but mature enough to have them included as part of the library
> - external - sort of incubator, place for more exotic tools,
> experiments, etc.
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> Charter Member of OSGeo, http://osgeo.org
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Christian Henning]

Hi there,

>>
>> 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:

http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/boost/gil/extension/toolbox/hsl.hpp

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:
http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/boost/gil/extension/toolbox/indexed_image.hpp

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?

Regards,
Christian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Mateusz Loskot]

Christian Henning wrote:

>>> 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.

Yes, I have noticed GIL feels complex myself too.
I've been playing with GGL since last April/May and I understand
well the learning curve is very steep if one wants to dig deeper
into internals.

> Let's consider the first type since it intervenes with gil source
> code much more closely. Have a look at: [...] To have a healthy
> developer base one has to the lead and do the necessary maintenance.

Very good point.

> For a user to have to go to two places to get the wanted
> functionality is quite a show stopper.

I have similar impression that it can be indeed.


To me, GIL organisation seems to be similar to GGL and perhaps GIL
followed by GGL will state some sort of example of how to arrange
extensions sup[port effectively.
Christian, thanks for sharing your experiences.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost