Instead of a static list, would it be better to point to our plugin registry and filter for org.apache.cordova? Also, does it make sense to reserve this namespace for Cordova use only?
-James Jong On Oct 15, 2013, at 6:49 PM, "Smith, Peter" <pet...@fast.au.fujitsu.com> wrote: > +1 for some kind of list > > Whenever the documented API refers to plugins which are not found in > what I thought was the official set plugins at > https://github.com/search?q=%40apache+cordova-plugin my brain hurts. > e.g. https://issues.apache.org/jira/browse/CB-5090 > > Peter. > > > -----Original Message----- > From: James Jong [mailto:wjamesj...@gmail.com] > Sent: Wednesday, 16 October 2013 5:17 AM > To: dev@cordova.apache.org > Subject: officially supported plugins from the Cordova community > > As we're breaking out and developing more and more plugins, one question > I have been getting is "what is the set of plugins officially supported > by the Cordova community?" It's unclear to me what defines this set. > Here's how I've been categorizing them. > > Supported > 1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer, > Compass, etc...). These plugins fall under the org.apache.cordova > namespace. > > Unsupported > 2) plugins not under org.apache.cordova namespace > 3) org.apache.cordova plugins under cordova-labs (like the new iOS > keyboard, status bar plugins) > > Gray areas > 4) Undocumented plugins that were formerly part of the core. For > example, the console plugin. This is a org,apache.cordova plugin, but > not documented as part of public APIs. Also, not all platforms support > it. Should we support it? If we support it, should we document the API > in our Cordova docs? > > Thoughts? Should we have a list of supported plugins in our > documentation to point Cordova users to? > > -James Jong > >
