[wp-hackers] Some Left-Field names for Canonical Plugins

[Mike Schinkel]

On Dec 8, 2009, at 7:36 AM, Doug Stewart wrote:
> I'm working from memory here, but when  Canonical plugins were discussed at
> WordCamp NYC, your specific two points were addressed.  The three most
> commonly-mentioned use cases for a CP were: podcasting, event calendaring
> and interfacing with Twitter.  In the case of the last two, there are
> literally tens, if not hundreds of plugins currently in the .org repository
> that take on Twitter and events in largely similar fashions which wastes
> effort on the part of developers (why recode what has already been solved to
> a 95% level for your use case? Why not simply contribute your tweaks or
> enhancements to the officially-supported Twitter plugin?) AND on the part of
> end users ("Okay, which of these Twitter plugins is worth installing? There
> are so many of them!").

Sounds like I really missed out by not being at WordCamp NYC!

You hit the nail on the head with those two examples!  I've struggled with both.  There's a definite need for a standard twitter infrastructure and repository for tweets, and a real need for a standard approach to events.  I've struggled with both of them, and still am. (As an aside, my Atlanta Startup Weekend team worked on a project called EventTank.com which, not ironically, is current built on WordPress.)

> In each of these cases, the use profile for the plugins is ever-so-slightly
> tangential to main line blogging and thus would merely contribute code bloat
> and interface cluttering were they to be added to core, at least for users
> that don't Twitter, plan events or publish a podcast.
> 
> Make sense?

Makes perfect sense.  

> I think someone could validly ask "Is there a
> definition for a plugin that would make it automatically eligible for
> Canonical status?", at which point we could set thresholds for star ratings,
> number of repetitive plugins in the repo, etc. I personally would be against
> setting metrics.
> 
> I think the actual best case is far more useful but far more frustrating --
> let's call it the Justice-Potter-Stewart-on-pr0n Principle*: "I can't define
> a canonical plugin, but I sure know one when I see one (and brother, your
> Etsy shopping cart app ain't one"**).

And I'm with you 100% on that too.  (Unless of course we disagreed when we saw one... ;-)

But seriously, what I'm hearing here is not the need for canonical plugins that expose some commonly needed UI but instead the need for optional baseline API functionality. In each of those three cases we don't really need elaborate UI functionality, we need shared infrastructure that plugins can build on.  Downloading tweets is easy, posting tweets is easy, storing tweets in a standard location is easy, and designing functions to load tweets from the database into arrays or objects is easy. OTOH there are a myriad of way to display tweets customized for the site owner and to make tweets in a UI optimized manner. Those latter features should be the realm of the plugin repository and the former should be in the form of standardized yet optional baseline plugins.

Drupal has already crossed this bridge and are solving it with specific APIs which you can find listed in the left sidebar here:  http://drupal.org/node/326.  Drupal's APIs include:

	• Batch API
	• Cache API
	• Contributed APIs
	• Database API
	• Field API
	• File API
	• Form API
	• JavaScript, AJAX, AHAH API
	• Localization API
	• RDF Mapping API
	• Schema API
	• XML-RPC API

WordPress is being stunted as a platform as long as it doesn't address this same need. Not exactly the same APIs but a recognition that there is a need for shared APIs and shared database schema that not everyone will use but that a significant minority will use.  (I'd say "Just add them to core" but then the torches and pitchforks come out with everyone chanting "Don't bloat the core!"  As long as we collectively have such an aversion to adding code that just sits on disk and doesn't run unless it's enabled we need an alternate solution to addressing shared APIs not used by the majority.)

Anyway I have another use case where I could really use standardized baseline functionality: a ratings plugin!  In a project I had the client wanted ratings to visually behave differently than any of the existing plugins and yet the existing plugins were not at all designed to be the baseline for others to modify.  So I wrote just such a ratings plugin designed to be the base of other plugins, mentioned here: http://mikeschinkel.com/wordpress-plugins/

Anyway, these type of plugins beg the question of having one plugin depend on another. If we can get the dependency built into the system, even if the dependencies only work for those optional baseline plugins then it would be a step in the right direction.

JMTCW anyway.

-Mike