incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: endless refactoring of plugins until "Cordova 2.x"
Date Mon, 26 Mar 2012 19:44:26 GMT
http://wiki.apache.org/cordova/RoadmapProjects


This wiki article needs some updating, possibly splitting it up into
separate pages. A separate article for the plugin target might be a good
idea.

On 3/26/12 11:43 AM, "Brian LeRoux" <b@brian.io> wrote:

>I'm far more in favor of shims that barf deprecation notices than
>maintaining two branches.
>
>Bryce/Patrick: I'll kick up a separate thread about roadmapping plugin
>stuff.
>
>
>On Mon, Mar 26, 2012 at 11:31 AM, Shazron <shazron@gmail.com> wrote:
>> I haven't done any JavaScript shims but I've eased the pain for users
>> needing to use plugins by adding compatibility headers for all the
>> PhoneGap/Cordova versions out there (0.96 to 1.5.0). See my plugin in
>> this issue and its README:
>> https://issues.apache.org/jira/browse/CB-330
>>
>> These compat. headers I include in CordovaLib but is so far
>> undocumented. What the procedure is, you would write a plugin meant
>> for 1.6.0 (ie the latest version), and for older version support, a
>> dev would included the appropriate compatibility headers.
>>
>> It's working great so far for the CDVLocalStorage plugin - from the
>> same plugin code base (one .m and .h) through the compat. headers,
>> everything just works with older versions as well. I assume we can do
>> something similar for JavaScript as well (shims).
>>
>> Shaz
>>
>> On Mon, Mar 26, 2012 at 11:15 AM, Bryce Curtis <curtis.bryce@gmail.com>
>>wrote:
>>> 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Šdeprecati
>>>>on
>>>>
>>>> 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.xm
>>>>l
>>>>
>>>> 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
View raw message