incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 21:09:42 GMT
We could use an 'engine' type specification similar to npm :
"engine": "node >= 0.4.1"

http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/


On Mon, Jun 25, 2012 at 2:02 PM, Filip Maj <fil@adobe.com> wrote:

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


-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message