Plugins: Architecture Wishlist

ginatrapani edited this page Jul 6, 2011 · 4 revisions
Clone this wiki locally

What should the plugin architecture grow into? This page is an ongoing draft of an answer to that question.

Current Plugin Types

  • ThinkUp Plugin — Abstract parent of all plugins. Comes with configuration options and activate/deactivate callbacks.
  • Crawler Plugin — Performs data gathering and crunching during scheduled cron jobs. Example: Twitter and Facebook plugins.
  • Dashboard Plugin — Views of a set of posts or user or follower count data, like most replied-to posts, or follower count over time. Example: Facebook and Twitter plugins.
  • Post Detail Plugin — Views of data associated with a single post and its replies, like a list of replies, a map of replies, a list of users who favorited that post, etc. Example: Twitter plugin.

Plugin Capabilities Needed

Some initial ideas on capabilities we want to add for plugins.

  • Plugin Dependences — Set a plugin to be dependent on another, and aware of whether or not the other is enabled. Example: The Twitter Realtime plugin is dependent upon the Twitter plugin.
  • Plugin Data Models and Migrations — Plugins should be able to create and modify their own meta-tables which left join onto core app tables. This work has begun: tu_instances has one plugin metatable, tu_instances_twitter. Plugin migrations should happen when the core app updates for activated plugins. If a plugin is deactivated, the migration should be performed when it is activated.
  • Plugin Objects — Along with their own db tables, plugins should be able to define their own model objects which extend core app objects. For example, the Twitter plugin could create a tu_posts_twitter meta-table, and extend the core app’s Post object into a Tweet object. The Tweet object would have all the member variables of the core app’s Post object, as well as tweet-specific fields defined in tu_posts_twitter.