incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 23:52:03 GMT
It's definitely a blocker IMO. 0.8 is the latest shipped version, and
it doesn't work with it.
Maybe you'll disagree, but users will.

On Mon, Jun 25, 2012 at 4:36 PM, Filip Maj <fil@adobe.com> wrote:
> Yep, 0.6.8.
>
> $ node -v
> v0.6.8
>
>
> On 6/25/12 4:32 PM, "Jesse" <purplecabbage@gmail.com> wrote:
>
>>0.6.8 ? Is your toaster unplugged Fil?
>>I am in windows and running without issue :
>>$ node -v => v0.6.18
>>
>>
>>On Mon, Jun 25, 2012 at 4:29 PM, Filip Maj <fil@adobe.com> wrote:
>>
>>> I wouldn┬╣t call that a blocker..
>>>
>>> Pluginstall works fine with node 0.6.8 too.
>>>
>>> I was using 0.6.6, some dependencies in pluginstall require at least
>>>node
>>> 0.6.7, so I upgraded to 0.6.8. Works fine.
>>>
>>> On 6/25/12 3:59 PM, "Shazron" <shazron@gmail.com> wrote:
>>>
>>> >pluginstall blocker:
>>> >https://github.com/alunny/node-xcode/issues/3
>>> >https://issues.apache.org/jira/browse/CB-631
>>> >
>>> >Only works with node 0.6.17
>>> >
>>> >
>>> >On Mon, Jun 25, 2012 at 2:09 PM, Jesse <purplecabbage@gmail.com> wrote:
>>> >> 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-shri
>>> >>nkwrap/
>>> >>
>>> >>
>>> >> 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
>>>
>>>
>>
>>
>>--
>>@purplecabbage
>>risingj.com
>

Mime
View raw message