Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.161.175 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: <CC0E158E.8F14%fil@adobe.com>
References: 
 <CANpVHHxWyWMk97H-2BSfiNMn9dtaqfW6v_+BhJa7JMXi2b1p3Q@mail.gmail.com>
	<CC0E158E.8F14%fil@adobe.com>
Date: Mon, 25 Jun 2012 13:28:27 -0700
Message-ID: 
 <CADVgkyNhWQNW2aAx81bcMYLS+az4d3-wf66kzs0x8tm+nN_Q=g@mail.gmail.com>
Subject: Re: Plugin Format and Spec
From: Brian LeRoux <b@brian.io>
To: callback-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

version number in the manifest so users have a sense of where it
should work; deprecation policy, etc on the cordova side

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