On Tue, Sep 14, 2010 at 09:36, Basile Starynkevitch <bas...@starynkevitch.net> wrote:
> I was thinking of adding a new plugin hook for builtins. We need to have a good use case before adding any more plugin hooks. In the case of this proposal, you also need a fixed code and a class for the builtins to work. In general, plugin support is in a state of flux, because we still have not agreed on a general set of APIs that we want to export to plugins. Instead of thinking of new places to add callbacks, I would like to take a couple of steps back and solve the API issue. What should plugins be allowed to see? Currently, we have an arbitrary collection of internal header files that we just expose to 3rd parties. This is sub-optimal. I would like to have a limited set of headers that contain exactly the functions and data structures that we allow plugin code to interact with. I believe that this problem will be largely solved when we make more progress in solving the internal modularity problem. So, I think we still have to solve that problem before we can think about the interfaces we want to export. Plugin hooks should only be added when an actual need arises. Adding hooks for the sake of adding hooks is not a good way to evolve this functionality. Diego.
