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:26:25 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message