incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: endless refactoring of plugins until "Cordova 2.x"
Date Mon, 26 Mar 2012 18:05:53 GMT
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):Š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:

Andrew is most of the way there in terms of defining an XML file
describing the integration of native source for a plugin, see:

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

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

View raw message