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

[Christopher O'Connell]

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.

~ Christopher

On Tue, Dec 8, 2009 at 2:29 PM, Aaron D. Campbell <aaron at xavisys.com> 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.
>
>
> Mike Schinkel wrote:
>
>> On Dec 8, 2009, at 2:46 AM, Pete Mall wrote:
>>
>>
>>> I've been working on a Twitter API and Google Data Protocol WordPress
>>> Client
>>> Library using WP_Http. It'll take care of the authentication and data
>>> transfer and would be easily extensible. A plugin writer would be able to
>>> use these libraries instead of re-inventing the wheel. If anyone is
>>> interested in contributing to these projects, please reply directly to
>>> me.
>>>
>>>
>>
>> Thanks Pete,  Perfect example of what I was discussing!
>>
>> So I'll ask others here, are these types of things appropriate or not
>> appropriate to add to the core?  My guess is that most people on the list
>> will chorus "that doesn't belong in the core!"  That's not my opinion, but
>> am I wrong?
>>
>> From my perspective it would be much better if there could be one API for
>> plugins to program for these types of things instead of many, especially if
>> there is a need for shared data or layering of functionality.  However, such
>> functionality is a no-mans land for WordPress and it advancement is thus
>> stunted; said functionality doesn't fit in the core by most people's
>> account, "market forces" don't foster its standardized across many plugins
>> and there is nowhere else for it to go.
>> To solve this?  One of:
>>  1.) Start allowing this kind of stuff into the core,
>> 2.) Support this kind of thing in the new canonical plugins, or 3.) Add a
>> 3rd entity, like canonical plugins in that they would be an official list
>> without duplication but for APIs instead of end user functionality.
>>
>> -Mike
>>
>> ___________
>>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>