Refine plugin architecture

[ginatrapani]

IMMEDIATE TODO'S:

• Detect which plugins are available
• Add an enable/disable front-end for available plugins
• Build plugin options interface so that configuration comes out of config.inc.php

BACKGROUND:
To make TT truly multi-service and enable users to build their own features into it, it's got to be pluggable. There should be allowances for both webapp plugins (data visualizations and custom listings, etc) as well as crawler plugins (new data sources like Facebook and Buzz).

As we build TT plugins, we will continue to refine the plugin architecture.

Here's an update on the current state of the pluggable architecture:

Files

• All plugin files are now located in a single place, common/plugins/.
• Each individual plugin has its own subfolder there, so the Twitter plugin is in common/plugins/twitter/.
• Templates for rendering plugin-specific things on the frontend are in a templates subdirectory, ie, common/plugins/twitter/templates/.
• Classes the plugin requires should be in a lib subdirectory, ie, common/plugins/twitter/lib/.
• Right now the only webapp plugin that's working is the configuration screen.

Database

• There are now tt_plugins and tt_plugin_options tables
• By default, the Twitter plugin is inserted and set to active in the tt_plugins table.

Future plans:

My vision is that ThinkTank plugins will work like WordPress: you drop a folder into the common/plugins/ directory, and it gets listed in the webapp as "Inactive." Click a link to activate the plugin (insert its row into the db, set is_active to 1, run any relevant installation routines) and the crawler and webapp will execute the methods it registers from there on in.

A hooks wishlist is underway here:
http://wiki.github.com/ginatrapani/thinktank/thinktank-plugin-hooks-wish-list

[CVi]

And custom Table fields

[ginatrapani]

I think I know what you mean, but just in case: can you explain?

[CVi]

The plugins also needs to be able to add custom fields to tables...
Or at least fields that can be joined in... (from a custom table)
for instance I'm trying myself and my phobia for API fiddling on TweetBlocker (adding Tweetblocker ratings to users) this needs eighter a field in users table OR custom table joined...
Did I make any sense?

[ginatrapani]

Yep, that makes sense... I think requiring plugins to create their own tables that join to existing ones would be safer.

[CVi]

I'm taking a crack at this one as I speak... I'm trying to to everything from scratch and then we can make the old code plug into the new one instead of making new code to fit the old one.

We should also make sure that any API we provide to te plugins does not get to spesiffic, we do want reusability right?

[ginatrapani]

Excellent... and yes.

[CVi]

http://github.com/cvi/thinktank/commit/9886f765a523dc71044f44fb5e5d76d91811d5e8

Have a look...

[ginatrapani]

Interesting, thanks cvi. I'll get this set up on my dev box and give it a test run today, and have more feedback later on tonight.

[CVi]

it is a quick'n dirty smack together so it barely works :p said that already, but the point here is to show an idea of how we could put it together (if there is a better saying for that, tell me :p)
Unfortunately it does not! solve the frontend plugin problem....

also the files in config_c is supposed to be compiled by install script (faster that way, database may be slowing it down)

It is just one simple plugin there... I'm not sure if i want to touch the crawlers directly (ill be happy to make APIs for them to use tho)

[ginatrapani]

Gina's take on this:
http://github.com/ginatrapani/thinktank/tree/pluggable

I'm going to work in this tree till I get the db changes done and do more testing, then I'll merge it into master.

[ginatrapani]

This is more of an ongoing project than a next action, so I'm putting the project on the TT roadmap wiki page, and I'll add discrete to-do's to the Issues list as they come up.