Plugin frameworks : 3 approaches to designing plugin APIs

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.

• Some reflections on developing plugins for all these three pieces of software.

• Ideas for using these methods.

• Design considerations.

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.