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 20:33:34 GMT
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
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>


Mime
View raw message