Thanks Brian, I was just going to respond saying the same thing but you beat me to it!
>What I'm trying to say is that I'm not at all inclined to +1/-1 until >we have agreed on the particulars of the change we seek. ^^ The above is the underlying issue. I suggest we do that as a first step. The referenced bug in this thread is just a small part of the overall work. Side note: deprecating + removing the "PhoneGap" JS global is not necessarily for plugins, it's a part of the Apache rename. The only changing part of the bug is removal of window.plugins. I prototyped a deprecation approach in a branch here (diff view): https://github.com/filmaj/incubator-cordova-js/compare/masterŠdeprecation Re: addResource/hasResource. These do not exist in cordova-js right now. They are effectively gone. They were only there for BB + Android anyways. I had one dude on IRC complain that we removed that in 1.5.0 without first deprecating. No huge outcry. Not saying that the fact we just axed it is good - it wasn't. We should have deprecated first, no doubt. My point about these two specific methods is, it already happened last release, so it is a moot point to discuss. Additionally we have had some work done to try to prototype what a final plugins-based approach to app development would look like, specifically Andrew Lunny's "pluginstall" work (which I believe started from a thread/discussion that happened on the list between Andrew and Pat). Here: https://github.com/alunny/pluginstall Andrew is most of the way there in terms of defining an XML file describing the integration of native source for a plugin, see: https://github.com/alunny/pluginstall/blob/master/test/plugin/plugin.xml The native plugin architecture has been around for a while. It is stable. Not much needs to be done there. The biggest question in my mind is how we want to handle the JavaScript. With cordova-js already implementing a basic module system with a hard API for the exec() function, we're actually not too far away. We should keep going in enumerating all these things that make up the plugin goal in this thread and drop whatever else comes up into a wiki page. It seems like it is a "safer" idea to slate all the plugin changes / API removals for 2.0. That being said, can we agree to drop deprecation notices into the agreed-upon APIs that will be axed leading up to 2.0? > I think we >can agree on the spirit of the focus of the work being a world of >plugins and tooling for automation. We haven't added much outside of >battery (and a new platform). > >1. The plugin architecture remains completely undocumented. >2. We do not support 3rd party plugins. >3. There is no automation or tooling. > >Are plugins from an API standpoint stable today? (I'm guessing not >when I think of things like addConstructor.) > >If they aren't stable, undocumented, unsupported by our effort, and a >work in progress for tooling: why are we concerned with breaking them? > >(Take all above with grain of salt, I think having a 2.x branch a good >idea, but will slow us down for no direct benefit to Cordova that I >can currently see.)
