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.
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
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@loskot.net> 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
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/g... 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/g... 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
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
participants (4)
-
Christian Henning -
Kai Schroeder -
Mateusz Loskot -
Tom Brinkman