incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryce Curtis <curtis.br...@gmail.com>
Subject Re: endless refactoring of plugins until "Cordova 2.x"
Date Mon, 26 Mar 2012 18:15:52 GMT
I agree that there's no way to know what plugins will look like in 2.x.
 Until then, I strongly believe we need to maintain the same (undocumented)
API that plugins currently rely upon, with the goal that 3rd party plugins
won't need to be updated again until 2.x - They already took a hit with
renaming in 1.5.

Regarding the plugin APIs (JS & native), we can't identify with certainty
which ones will be deprecated until we are further along with the 2.x
plugin architecture, so we shouldn't confuse users until details are worked
out and prototypes running.  Regarding API stability, while we have
discussed deprecating methods like addConstructor, window.plugins, etc.,
 the fact that they have remained consistent for many releases (well over a
year or 2) has led to their wide use.

After 1.6.0 release, we should schedule a plugin meeting to go over the
priorities, what's been done to date, and where it's going.

On Mon, Mar 26, 2012 at 1:05 PM, Filip Maj <fil@adobe.com> wrote:

> 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.)
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message