Plugins: Architecture Wishlist

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.