incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 23:36:06 GMT
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