Plugin frameworks : 3 approaches to designing plugin APIs
|Tags||plugins, extending, metaprogramming|
This talk is a somewhat opinionated "discussion" of 3 different approaches to designing a plugin API for a piece of software. Each approach is accompanied by an example. The talk derives from some recent work I did with py.test and is an expanded version of a discussion I had on stack overflow.
The general outline of the talk is as follows. I've not written it yet so it will be a little different from this.
General talk on extensibility and why it's a good thing
How Python and dynamic languages in general make this easy to do.
Three ways of doing this
The Javaesque approach used in Eclipse (and other such software)
- Some comments on the approach (subclassing advertised classes and altering functionality)
- Comments on the disadvantages of this method.
- Trac (a once popular web based project management tool) is used as an example for this.
The hooks approach used by py.test (and my own project milverton).
- Some comments on the lower entry barrier for this system and how it facilitates a larger number of plugins.
- Disadvantages of this method.
- Milverton (an application protocol debugging proxy) will be used as an example (if I can get it into proper shape by then). Otherwise, py.test (a test framework) will be used.
The "Embedded scripting language" style used by Emacs.
- Comments on the very low entry barrier of embedding a full blown scripting language inside the program.
- Emacs (the extensible text editor) will be used as an example.
- The Javaesque approach used in Eclipse (and other such software)
Some reflections on developing plugins for all these three pieces of software.
Ideas for using these methods.
Python enthusiast tinkering with Python and other dynamic languages for the past 10 years or so. Organiser of PyCon India 2009 and 2010. Blogs (sometimes) at http://nibrahim.net.in/journal.