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 Tue, 26 Jun 2012 00:19:13 GMT
Talked to Brian and Anis.

It was explained to me that even numbered versions are considered
unstable, etc - so it's expected for devs to use a more stable
version.

I'm just considering the most common scenario - where people will
download the latest node version 0.8 (regular dev users, not us)

There's three approaches for us:
1. They downloaded 0.8 - tell them to downgrade, using
https://github.com/isaacs/nave to 0.6
2. Upgrade our plugin to work with 0.8
3. Tell them to clean install 0.6 http://nodejs.org/dist/

My thinking is #2 would be easiest for users, but if we are going with
0.6, we will have to document the steps etc for #1 and/or #3

Shaz

On Mon, Jun 25, 2012 at 4:52 PM, Shazron <shazron@gmail.com> wrote:
> 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