On Fri, Oct 1, 2010 at 3:03 PM, Leo Sutic <leo.su...@gmail.com> wrote:
> > Libplugin assumes that the application has extension points where > plugins can be added. Each extension point can have, if I understand the > docs and illustrations right, *one* plugin; since the function pointer > that is the extension point can only point to one place. > Not really, that's just one of the things it can do. Join-points have a stack that can call the next function down the stack (which can call the next one & etc) which could be used to reproduce the imbuf image loading function (try all the image loaders until one succeeds) for example. > We need for each extension point to have more than one plugin, and to be > able to identify and select between them at runtime. > > You can get a plugin loaded into a function list like node or operator (or the current plugin system) loading functions pretty easily, just needs a custom loading function. In (evil) xml it would be something like <texture symbol="foo"> where the parser would call the plugin loader function pointer on the "texture" struct which in this case would probably fetch the symbol 'foo' and register it with blender's texture function. Or something different, whatever you like. The key is that when it sees 'texture' it finds a struct named 'texture' in the list and uses that to parse the xml node so you can hang all sorts of different functionality off the basic library. Like I was saying, the libffi (aspect) stuff is just cowbell... _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
