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

[Mike Schinkel]

On Dec 8, 2009, at 11:57 AM, Christopher O'Connell wrote:
> We have (and will soon have
> better) custom post types, I think we need to try an encourage people to
> work within this structure to store and manage their data.

Agreed.

> Aren't calendar events pretty much just a custom "event" post type? IMHO,
> we need to encourage people to work with the database that's already there,
> rather than automatically going for creating a new DB. On the other hand,
> it's not the easiest thing in the world to use: in particular, where do you
> store things? The "meta" table seems the obvious place, but then what goes
> into the actual post table? An empty post? A serialization of the data? All
> the data jammed together?

So therein lies the problem.   Before post types one event plugin creates a set of tables and another uses custom fields.

Now with custom post types most will be using custom fields (though not all) but we still have the compatibility problem.  Both plugins use an "event" post type but one plugin uses custom fields called "Start Date" and "Start Time" and another uses "Event Date" and "Event Time."  Now both provide complimentary functionality but because they use incompatible custom fields they can't be used together.  That's the problem a shared baseline events plugin could solve.

> I really, really agree on the shared baseline. There will always be someone
> who wants slightly different baseline functionality, but there's a lot of
> lower level problems that are probably solved tens if not dozens of times.
> If there were "canonical" libraries I would feel much more comfortable using
> them.

Good deal!

> Finally, I want to affirmatively vote against using the word "premium". In
> general usage on the web, premium means "for money", and there are lots of
> "premium" things in the WP community that are for money (and lots of premium
> things outside of the WP community that are for money). Appropriating the
> word premium won't make those things disappear, it will just confuse people.
> I think it makes sense to chose a word that implies the quality, but still
> free. Canonical or Core would be my votes.

Agreed on not using "Premium."

On Dec 8, 2009, at 12:48 PM, Eric Marden wrote:

> On Dec 8, 2009, at 11:57 AM, Christopher O'Connell wrote:
>> Canonical or Core would be my votes
> I voted for Core, since it already has a strong connotation in the community.

Wouldn't "Core" be confused with the current use of "Core?"
Or are you saying "Core Plugins" which mean they ship with "Core?"

On Dec 8, 2009, at 4:29 PM, Aaron D. Campbell wrote:
> I have two plugins like this (MailChimp Framework <http://wordpress.org/extend/plugins/mailchimp-framework/> and PayPal Framework <http://wordpress.org/extend/plugins/paypal-framework/>).  I really don't think they belong in Core, and I'm also not sure they really belong as canonical plugins.  Since they're only really useful to other programmers, I think they're perfectly fine just staying in the wordpress.org repository as a general plugin.

Status quo doesn't solve some very real problems.  First is that I would either not use your framework or I would copy your plugin into mine to keep end users from the complexity of having to install both yours and mine. If two plugins did copy your framework it could result duplicated and potentially mismatched versions at best or in incompatibilities between the two plugins at worst.

And with out them being designated as "canonical" in some way then people are much less likely to find yours and/or have confidence that it will continue to be supported.  Without being canonical if a developer doesn't like exactly how you implemented it they might just go build a competing version and fragment the market thus making it harder for people to understand which to use and possibility even spawning incompatible child plugins.  If yours were canonical then the incentive would be to either learn to live with your approach and/or contribute code to yours to enhance it to be better fit for purpose.


On Dec 8, 2009, at 5:46 PM, Christopher O'Connell wrote:
> Here's the problem with that: If there's not a canonical version, there's
> potential side effects and conflicts. Furthermore, those additional plugins
> have to be sent along with plugins. Then, you potentially end up with
> several plugins, each of which has a different (and potentially conflicting
> version) of the same library. Or, the user has to manually install a bunch
> of libraries. Plugins really need to be able to get their own dependencies,
> possibly prompting the user as to whether they can install the dependency.

What he said. :-)

-Mike