incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 20:12:30 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message