incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 21:02:10 GMT
Ideally, I would think we do NOT plan on doing that post-2.0. That said,
our current deprecation policy, last I checked, was "6 months from now",
which does not guarantee that the API will not change between minor
revisions.

Thus, the conversation turns back to project versioning and deprecation.

Mike and I spoke about this this morning. I think both of us support the
idea of moving to semantic versioning for 2.0 and beyond.

On 6/25/12 1:45 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:

>Agreed fil, but are we planning on doing that for future releases ? If yes
>that YAH we should support versions and the solution you described is
>certainly an option. But if I were a plugin developer, I would not want to
>update it every month to keep up with Cordova releases.
>I don't disagree that there could be an Cordova version in the manifest
>file that allows plugin developers to target a specific version of Cordova
>(which would mean that the plugin was tested with that version but might
>also work with newer versions).
>
>On Mon, Jun 25, 2012 at 1:33 PM, Filip Maj <fil@adobe.com> wrote:
>
>> Yes, it has changed every month. Pretty much every minor revision from
>>1.0
>> to 1.9 has changed the API (at least on Android).
>>
>> On 6/25/12 1:26 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>
>> >Right but does the plugin interface change every month too ? A plugin
>>that
>> >works with Cordova 1.x.x is not supposed to work with Cordova 1.y.y ?
>> >
>> >On Mon, Jun 25, 2012 at 1:18 PM, Filip Maj <fil@adobe.com> wrote:
>> >
>> >> You don't see any reason why plugins should support different
>>versions
>> >>of
>> >> cordova? Cordova gets released every month. This seems like a pretty
>> >> important thing to figure out IMO
>> >>
>> >> On 6/25/12 1:12 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>> >>
>> >> >I think we should agree on a spec (plugin package and plugin
>>interface)
>> >> >and
>> >> >stick to it. As long as we don't break the plugin interface, I don't
>> >>see
>> >> >any reason why plugins should support multiple versions of Cordova.
>>If
>> >> >there are any, I'd love to hear them.
>> >> >
>> >> >On Mon, Jun 25, 2012 at 1:01 PM, Filip Maj <fil@adobe.com> wrote:
>> >> >
>> >> >> Back onto the versioning question..
>> >> >>
>> >> >> 1. Do we want to support different version of the cordova
>>framework
>> >>in
>> >> >> plugins, within a single repo, across versions that changed the
>> >> >> native/javascript plugin API?
>> >> >> 2. How?
>> >> >>
>> >> >> If the answer to (1) is yes, one idea for (2) might be nesting
>> >>another
>> >> >> directory level in the all of the source directories that contains
>> >>the
>> >> >> version number supported. For example:
>> >> >>
>> >> >> src/android/1.5.0/*.java
>> >> >> src/android/1.8.1/*.java
>> >> >> www/1.5.0/childbrowser.js
>> >> >> www/1.8.1/childbrowser.js
>> >> >>
>> >> >> Could get gnarly real quick though. Another, cleaner
>>implementation
>> >>in
>> >> >> terms of file system "noise" might be to employ a git branches
>> >> >> convention.. But that would enforce a git dependency.
>> >> >>
>> >> >> Just brainstorming / thinking out loud. Both are probably bad
>>ideas
>> >>:)
>> >> >>
>> >> >> On 6/25/12 11:41 AM, "Michael Brooks" <michael@michaelbrooks.ca>
>> >>wrote:
>> >> >>
>> >> >> >We may also want to describe testing from JavaScript and Native.
>> >> >> >
>> >> >> >I would also like to see a repository called
>> >>"cordova-plugin-template"
>> >> >> >that
>> >> >> >is a boilerplate to start writing any plugin. The idea is that
>>users
>> >> >>start
>> >> >> >with something that works, with tests, and documentation
>> >>boilerplate -
>> >> >> >perhaps it can be an echo plugin since that has a minimal
>>footprint.
>> >> >> >
>> >> >> >On Mon, Jun 25, 2012 at 11:28 AM, Filip Maj <fil@adobe.com>
>>wrote:
>> >> >> >
>> >> >> >> Looks great. I'll add some detail to the list you have
here.
>>I'd
>> >> >> >>recommend
>> >> >> >> tweaking the order a little bit; introducing the JS before
the
>> >>native
>> >> >> >>APIs.
>> >> >> >>
>> >> >> >> # Plugin Author Guide
>> >> >> >>
>> >> >> >> - plugin package format -> points to Andrew's plugin
spec
>> >> >> >> - js api
>> >> >> >> --- basically documenting exec(). Service, action, callbacks,
>> >> >>arguments.
>> >> >> >> What about how arguments are translated from JS types
(string,
>> >> >>number,
>> >> >> >> objects, etc) to native types for each platform?
>> >> >> >>
>> >> >> >> - native api
>> >> >> >> --- ios
>> >> >> >> --- android
>> >> >> >> --- blackberry
>> >> >> >> --- windowsphone
>> >> >> >> --- bada
>> >> >> >>
>> >> >> >>
>> >> >> >> On 6/25/12 11:16 AM, "Brian LeRoux" <b@brian.io>
wrote:
>> >> >> >>
>> >> >> >> >Biggest question is how to document. My thinking is
that we
>>want
>> >>to
>> >> >> >> >specify the PluginPackage so that PluginInstall works.
So the
>> >>docs
>> >> >> >> >would read like this:
>> >> >> >> >
>> >> >> >> ># Plugin Author Guide
>> >> >> >> >
>> >> >> >> >- plugin package format
>> >> >> >> >- native api
>> >> >> >> >--- ios
>> >> >> >> >--- android
>> >> >> >> >--- blackberry
>> >> >> >> >--- windowsphone
>> >> >> >> >--- bada
>> >> >> >> >- js api
>> >> >> >> >
>> >> >> >> >Thoughts? (If this looks good I will update the issue.)
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >On Mon, Jun 25, 2012 at 10:50 AM, Filip Maj <fil@adobe.com>
>> >>wrote:
>> >> >> >> >> Hah Michael and I were just talking about that..
>> >> >> >> >>
>> >> >> >> >> I will send a pull request to Andrew's draft
spec
>> >> >> >> >>
>> >> >> >> >> On 6/25/12 10:46 AM, "Brian LeRoux" <b@brian.io>
wrote:
>> >> >> >> >>
>> >> >> >> >>>npm does this w/ an 'engines' attribute on
package.json
>> >> >> >> >>>
>> >> >> >> >>>On Mon, Jun 25, 2012 at 10:26 AM, Filip Maj
<fil@adobe.com>
>> >> wrote:
>> >> >> >> >>>> One more thing that came to mind is how
to support
>>different
>> >> >> >>versions
>> >> >> >> >>>>of Cordova? Any ideas?
>> >> >> >> >>>>
>> >> >> >> >>>> From: Andrew Lunny
>> >><alunny@gmail.com<mailto:alunny@gmail.com>>
>> >> >> >> >>>> Reply-To: "alunny@gmail.com<mailto:alunny@gmail.com>"
>> >> >> >> >>>><alunny@gmail.com<mailto:alunny@gmail.com>>
>> >> >> >> >>>> To: Default User Nam <fil@adobe.com<mailto:fil@adobe.com>>
>> >> >> >> >>>> Cc:
>> >> >> >> >>>>"callback-dev@incubator.apache.org<mailto:
>> >> >> >> callback-dev@incubator.apache
>> >> >> >> >>>>.o
>> >> >> >> >>>>rg>"
>> >> >> >> >>>><callback-dev@incubator.apache.org<mailto:
>> >> >> >> callback-dev@incubator.apache
>> >> >> >> >>>>.o
>> >> >> >> >>>>rg>>
>> >> >> >> >>>> Subject: Re: Plugin Format and Spec
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> On 11 June 2012 13:50, Filip Maj
>> >> >> >><fil@adobe.com<mailto:fil@adobe.com
>> >> >> >> >>
>> >> >> >> >>>>wrote:
>> >> >> >> >>>> Nice work Andrew! I suggest taking this
and moving to a
>> >>cordova
>> >> >> >>wiki
>> >> >> >> >>>>page
>> >> >> >> >>>> (assuming all committers are on board
to adopting this as
>>the
>> >> >>basis
>> >> >> >> >>>>for
>> >> >> >> >>>>a
>> >> >> >> >>>> plugin spec)
>> >> >> >> >>>>
>> >> >> >> >>>> A link on the Cordova wiki is probably
the best place to
>> >>start
>> >> >>- we
>> >> >> >> >>>>can
>> >> >> >> >>>>get some more feedback from plugin authors
and app
>>developers
>> >> >>(i.e.
>> >> >> >> >>>>keep
>> >> >> >> >>>>this as "a way to write plugins" rather
than "the official
>> >>way to
>> >> >> >>write
>> >> >> >> >>>>plugins").
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Is target-dir necessary for the <source-file>
element? For
>> >>Java
>> >> >> >>files,
>> >> >> >> >>>>the
>> >> >> >> >>>> tooling could take a peak inside the
.java file and
>>extract
>> >>out
>> >> >>the
>> >> >> >> >>>> package name from the file, no? Phonegap
build already
>>does
>> >>this
>> >> >> >> >>>>doesn't
>> >> >> >> >>>> it?
>> >> >> >> >>>>
>> >> >> >> >>>> PhoneGap Build did do this, but no longer
supports
>>uploading
>> >> >> >>arbitrary
>> >> >> >> >>>>Java files. Only plugins with a manifest
are supported.
>> >> >> >> >>>>
>> >> >> >> >>>> I'm torn - one of the goals of this format
is to make it
>>as
>> >> >>easy as
>> >> >> >> >>>>possible to write tools that use it as
possible. Right
>>now, a
>> >> >>tool
>> >> >> >> >>>>reads
>> >> >> >> >>>>one file (plugin.xml) and moves source
files (ignoring
>>config
>> >> >>files
>> >> >> >>for
>> >> >> >> >>>>the moment). I'd prefer it wasn't "read
one file, then read
>> >>each
>> >> >> >>.java
>> >> >> >> >>>>file to discover where to move it".
>> >> >> >> >>>>
>> >> >> >> >>>> One option is to use the id attribute
on the top-level
>>plugin
>> >> >> >>element
>> >> >> >> >>>>to resolve the path, but that doesn't
handle the case where
>> >> >> >>different
>> >> >> >> >>>>Java files will have different paths.
I wonder if there are
>> >>more
>> >> >> >> >>>>complex
>> >> >> >> >>>>plugins around we can try to convert to
see where the pain
>> >>points
>> >> >> >>are.
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> Adding the ability to modify existing
parts of a native
>> >> >>platform's
>> >> >> >> >>>>config
>> >> >> >> >>>> document to the <config-file> portion
might be needed..
>> >>Although
>> >> >> >>Ive
>> >> >> >> >>>>yet
>> >> >> >> >>>> to dig up a use case. Will dig around
more.
>> >> >> >> >>>>
>> >> >> >> >>>> Agreed - also things like target OS/SDK
versions may be
>> >> >>required by
>> >> >> >> >>>>certain plugins (i.e. this plugin uses
an iOS 6 API, so we
>> >>need
>> >> >>to
>> >> >> >> >>>>update your project to iOS 6). Probably
the best approach
>> >>there
>> >> >>is
>> >> >> >>to
>> >> >> >> >>>>warn/prompt the user before proceeding.
>> >> >> >> >>>>
>> >> >> >> >>>> +1 agree that <resource-file> and
<header-file> is
>>redundant.
>> >> >> >>Tooling
>> >> >> >> >>>> should be able to distinguish this so
merging with
>> >><source-file>
>> >> >> >> >>>>makes a
>> >> >> >> >>>> lot of sense.
>> >> >> >> >>>>
>> >> >> >> >>>> Looking good!
>> >> >> >> >>>>
>> >> >> >> >>>> On 6/8/12 6:40 PM, "Andrew Lunny"
>> >> >> >> >>>><alunny@gmail.com<mailto:alunny@gmail.com>>
wrote:
>> >> >> >> >>>>
>> >> >> >> >>>>>Hi all,
>> >> >> >> >>>>>
>> >> >> >> >>>>>I've posted to this list before about
pluginstall[1], the
>> >>tool
>> >> >>I've
>> >> >> >> >>>>>developed as part of working on PhoneGap
Build and
>>requiring
>> >> >> >> >>>>>programmatic
>> >> >> >> >>>>>installation of Cordova plugins.
>> >> >> >> >>>>>
>> >> >> >> >>>>>I've now written up a spec for the
format that pluginstall
>> >>uses
>> >> >>- I
>> >> >> >> >>>>>think
>> >> >> >> >>>>>it's generally useful for Cordova
plugin installation and
>> >> >> >> >>>>>manipulation.
>> >> >> >> >>>>>The
>> >> >> >> >>>>>spec is available on GitHub:
>> >> >> >> >>>>>https://github.com/alunny/cordova-plugin-spec
>> >> >> >> >>>>>
>> >> >> >> >>>>>Issues and/or pull requests and/or
forks welcome.
>> >> >> >> >>>>>
>> >> >> >> >>>>>Cheers,
>> >> >> >> >>>>>Andrew
>> >> >> >> >>>>>
>> >> >> >> >>>>>[1] https://github.com/alunny/pluginstall
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>


Mime
View raw message