These are just a bunch of not necessarily coherent thoughts about writing our code to support plugins in the editor.
when I first started working on RMPY and I made the decision to provide a plugin interface I stent also two months researching and thinking on how to design it. when I wrote the Kernel module I wrote the best structure I could think up.
for the most part I think the concept and ideas in the structure are sound. But it alone doesn't provide a good plugin interface.
there is this concept in the kernel called events. events raised in the kernel and the kernel calls all the functions registered to that event. recently I realized that there is a problem with this. if the code run in one of those function calls raises another event in the kernel the stack level of the entire program goes up a layer until all those function return and there is a potential for infinite loops (events raising event raising the first event) this can be fixed by preventing code running from an event from raising another event in the kernel. I don't see a problem with this and it would take a matter of seconds to implement. events are meant to interject code thats why they are so useful for plugins but I don't think they should be used to change the flow of the program (unless the change is done by changing a value and when the effected part updates the change is made)
basically there are two ways for the editor to be extend. one is to use events and inject code, extensions made this way by their nature can stack. and two replacing and entire component; this kind of extensions CAN'T stack if there are multiple plugins trying to replace the same component unless special attention is made by the plugin developer to support the extension of his component.
also there needs to be a way to wrap event calls an catch errors, a protected function call if you will. I can;t think of a way to do the same thing for components, we'll just have to cache errors in the main loop and trust in the author of the component that errors won't happen
also we need to implement some sort of logging interface like the we have in the engine.
with all this in mind when coding the components in our system we need to structure out code so that there are strategic places events can be raised that plugins can attach themselves to and actually be useful. there is a feature of event that you can pass objects as arguments to the functions registered to the event, so if we create an event we need to document it along with it's call signature so that plugin developer know of its existence.
we have the framework for plugins for the most part done. we just need a few utilities function like the ones listed above and to provide the hooks into the program for developers to use.
Ah, you came across events causing themselves to be raised. xD I've come across the same problem while working in C#.
Yes, the only way would be if we divided plugins into event extensions and whole components. This system would have to be laid out entirely before we can decide an alternative. I guess we should go with this for now. If we can come up with a better solution, let's hope there aren't already too many plugins out there that have to be edited to make them work with the new plugin system.
I didn't necessarily come across it I just realized that it could happen.
I agree that it works for now, I just can't help thinking that it's a bit overly complicated. but then we're exposing a complex program to extension.