You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com> on 2014/03/01 19:39:18 UTC
Proposal: hooks support for plugins
Hi, I have an idea how we can add more flexibility to plugin developers and would like to discuss it.
Note, right now we have Application Developers - someone who use Cordova for developing applications and Plugin Developers - someone who creates plugins so that Application Developers can use them. For Application Developers we expose hooks so that they can customize their build/package/etc process. I want us to provide similar sort of flexibility to Plugin Developers so that they can go beyond of <source/>, <framework/> tags and get mechanism to add custom installation, build logic required by a plugin. Example usage will include: downloading/compiling additional binaries, marking source file to be copied to output dir, changing target build platform, etc. At present time the steps described could be only achieved by hooks manually added by Application Developer, but the right way is to allow Plugin Developer to expose this as part of plugin definition.
I personally like how npm-scripts[1] work so propose to introduce additional <scripts> section in plugin.xml, for example
<scripts preinstall="preinstall.js" postinstall="afterinstall.js" />
preinstall.js is called before plugman.raw.install(platform, platformRoot, path.basename(dir), pluginsDir, options) and could be used to check system requirements, download/compile required libraries, etc
afterinstall.js is called after and could be used to add/configure additional project references, etc
uninstall.js - for discussion, could be used for clean up, etc
As for required parameters I think we should pass at least application folder and target platform.
Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014 (7pm EST)
[1] https://www.npmjs.org/doc/misc/npm-scripts.html
-Sergey
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Sat Mar 1 01:39 PM, Sergey Grebnov (Akvelon) wrote:
>
> <scripts preinstall="preinstall.js" postinstall="afterinstall.js" />
>
> preinstall.js is called before plugman.raw.install(platform, platformRoot,
> path.basename(dir), pluginsDir, options) and could be used to check system
> requirements, download/compile required libraries, etc
>
> afterinstall.js is called after and could be used to add/configure additional project
> references, etc uninstall.js - for discussion, could be used for clean up, etc
>
> As for required parameters I think we should pass at least application folder and
> target platform.
>
> Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014 (7pm EST)
>
Two issues I can think of:
- uninstall() needs to know which files where installed by either the preinstall or afterinstall script.
- I'd like users to be able to pass options/arguments to the script (overriding default build options)
e.g.
cordova plugin add some.db --utf8 false
For unix people, it's like a ./configure --utf8 false --with-stuff && make install
But can't do this right now with cordova since we'd need to store the plugin install arguments "--utf8 false" to update a plugin.
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Fri Apr 18 11:35 AM, Sergey Grebnov (Akvelon) wrote:
> Sound like most of us prefer module.export. Cool, will update the code today
> and let you know once this is done.
>
> Since we will be moving to cordova-lib the next action item here could be
> creating uniform hooks with shared code for both application level and plugin
> level hooks. Thoughts?
>
+1, great for moving this forward. Makes sense as a module in cordova-lib.
Would be nice to support inline <script></script> tags.
Agree with using same mechanism for the cli hooks.
Re: Proposal: hooks support for plugins
Posted by Brian LeRoux <b...@brian.io>.
if we pass in a reference though ideally things like cordova-lib-plugin-ls
can be require'd in appropriately as their own modules
On Tue, Apr 22, 2014 at 9:15 AM, Michal Mocny <mm...@chromium.org> wrote:
> I was recently trying to solve a problem with hooks: how do I require()
> cordova itself? (I was trying to call "cordova plugin ls" and ended up
> just writing my own crude inline implementation instead). If the hooks
> themselves are being require()-ed, does it simplify that problem?
>
> -Michal
>
>
> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > There are some *disadvantages* to not sub-shelling out for hooks:
> > - Harder to capture their stdio (certainly do-able though by swapping out
> > system.std* for the duration of the hook)
> > - Harder to handle script failures (e.g. if they throw an uncaught
> > exception, we would like to be able to say "This hook script failed:
> > foo.js")
> > - Maybe this is doable, by storing a global exception-was-thrown
> > callback?
> > - Gives hooks the ability to mess up cordova's environment (although
> maybe
> > the vm thing addresses this?)
> >
> > Would like to see tests for these things added before we launch this
> > feature.
> >
> >
> >
> > On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > v-segreb@microsoft.com> wrote:
> >
> > > +1, I will name it as 'context'
> > >
> > > Thx!
> > > Sergey
> > > -----Original Message-----
> > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > > Sent: Tuesday, April 22, 2014 7:34 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Proposal: hooks support for plugins
> > >
> > > On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > > > module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> > > > console.log('hook.js: ' + platform);
> > > > console.log('hook.js: ' + projectDir);
> > > > console.log('hook.js: ' + pluginDir);
> > > > console.log('hook.js: ' + cmdLine);
> > > >
> > >
> > > Personnaly prefer:
> > >
> > > > module.exports = function(hookApi) {
> > > > console.log('hook.js: ' + hookApi.platform);
> > > > console.log('hook.js: ' + hookApi.projectDir);
> > > > console.log('hook.js: ' + hookApi.pluginDir);
> > > > console.log('hook.js: ' + hookApi.cmdLine);}
> > >
> > > Make it easier to pass other stuff in the future & using a sandoxed
> > > hookApi object.
> > >
> > >
> > >
> >
>
Re: Proposal: hooks support for plugins
Posted by Shazron <sh...@gmail.com>.
Question, from the Cordova Hooks doc:
"This directory used to exist at .cordova/hooks, but has now been
moved to the project root." -> doesn't this imply that .cordova/hooks
does not work anymore, you should use hooks/ ?
On Wed, Jul 9, 2014 at 9:24 AM, Sergey Grebnov (Akvelon)
<v-...@microsoft.com> wrote:
> I've just sent a PR with unified hooks implementation for both cordova app and plugins developers. Please review
> https://github.com/apache/cordova-lib/pull/55
>
> More details
> https://github.com/MSOpenTech/cordova-lib/commit/952690b7d7b42962b4e246c2b84c309846bf8750?short_path=8c918a9#diff-8c918a9f452feb5e3ef3339749806fc3
>
> * Hooks can be defined in .cordova/hooks/hook_type, hooks/hook_type directories, config.xml (by application developers) and plugins/.../plugin.xml (by plugins developers)
> * Javascript hooks retrieved from config.xml and plugins/.../plugin.xml will be run via new module loader with special Context argument passed. This object represents current hook script execution context including hook type, cordova version, paths, plugin info and other special utility modules.
> * Introduced before_plugin_install, after_plugin_install and before_plugin_uninstall hooks.
>
> Thx!
> Sergey
> -----Original Message-----
> From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> Sent: Friday, May 16, 2014 4:08 AM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: hooks support for plugins
>
> Addressed code review notes, added spec tests, moved to cordova-lib repo.
> https://github.com/apache/cordova-lib/pull/12
>
> Thx!
> Sergey
> -----Original Message-----
> From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> Sent: Wednesday, April 30, 2014 2:08 PM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: hooks support for plugins
>
> Updated code as per latest notes. Do we ready to merge this?
>
> https://github.com/apache/cordova-plugman/pull/74
>
> Thx!
> Sergey
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
> Sent: Tuesday, April 22, 2014 10:39 AM
> To: dev
> Subject: Re: Proposal: hooks support for plugins
>
> Passing in a reference is not a bad idea, though that implies that there is a single top-level `cordova` object to reference. Not sure if thats the plan so far.. though it could be.
>
> Probably easier to just support require() of cordova bits, but I'm not sure how to get that to work.
>
>
> On Tue, Apr 22, 2014 at 1:32 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> shhh
>>
>>
>> On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage
>> <purplecabbage@gmail.com
>> >wrote:
>>
>> > If you need a shell script, that can be easily hidden behind the
>> > node module.
>> >
>> > Sent from my iPhone
>> >
>> > > On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote:
>> > >
>> > > Maybe harsh but I'm in favor of abandoning shell scripts
>> > > altogether and forcing modules as the way for hooks. Cross platform yada yada.
>> > >
>> > >
>> > >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve
>> > >> <ag...@chromium.org>
>> > wrote:
>> > >>
>> > >> Very good point. Seen at least one other bug report that
>> > >> struggled
>> with
>> > >> this use-case.
>> > >>
>> > >> I *think* hooks-as-a-module makes it easier.
>> > >>
>> > >> Just to be clear - I am also in favour of allowing hooks to be
>> > >> npm
>> > modules.
>> > >> Possible there's use in continuing to support bash scripts as
>> > >> hooks,
>> but
>> > >> there are definitely advantages to allowing modules.
>> > >>
>> > >>
>> > >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny
>> > >> <mm...@chromium.org>
>> > >> wrote:
>> > >>
>> > >>> I was recently trying to solve a problem with hooks: how do I
>> require()
>> > >>> cordova itself? (I was trying to call "cordova plugin ls" and
>> > >>> ended
>> up
>> > >>> just writing my own crude inline implementation instead). If
>> > >>> the
>> hooks
>> > >>> themselves are being require()-ed, does it simplify that problem?
>> > >>>
>> > >>> -Michal
>> > >>>
>> > >>>
>> > >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <
>> agrieve@chromium.org
>> > >>>> wrote:
>> > >>>
>> > >>>> There are some *disadvantages* to not sub-shelling out for hooks:
>> > >>>> - Harder to capture their stdio (certainly do-able though by
>> swapping
>> > >> out
>> > >>>> system.std* for the duration of the hook)
>> > >>>> - Harder to handle script failures (e.g. if they throw an
>> > >>>> uncaught exception, we would like to be able to say "This hook script failed:
>> > >>>> foo.js")
>> > >>>> - Maybe this is doable, by storing a global
>> > >>>> exception-was-thrown callback?
>> > >>>> - Gives hooks the ability to mess up cordova's environment
>> > >>>> (although
>> > >>> maybe
>> > >>>> the vm thing addresses this?)
>> > >>>>
>> > >>>> Would like to see tests for these things added before we launch
>> > >>>> this feature.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
>> > >>>> v-segreb@microsoft.com> wrote:
>> > >>>>
>> > >>>>> +1, I will name it as 'context'
>> > >>>>>
>> > >>>>> Thx!
>> > >>>>> Sergey
>> > >>>>> -----Original Message-----
>> > >>>>> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
>> > >>>>> Sent: Tuesday, April 22, 2014 7:34 AM
>> > >>>>> To: dev@cordova.apache.org
>> > >>>>> Subject: RE: Proposal: hooks support for plugins
>> > >>>>>
>> > >>>>>> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
>> > >>>>>> module.exports = function(platform, projectDir, pluginDir,
>> > >> cmdLine) {
>> > >>>>>> console.log('hook.js: ' + platform);
>> > >>>>>> console.log('hook.js: ' + projectDir);
>> > >>>>>> console.log('hook.js: ' + pluginDir);
>> > >>>>>> console.log('hook.js: ' + cmdLine);
>> > >>>>>
>> > >>>>> Personnaly prefer:
>> > >>>>>
>> > >>>>>> module.exports = function(hookApi) {
>> > >>>>>> console.log('hook.js: ' + hookApi.platform);
>> > >>>>>> console.log('hook.js: ' + hookApi.projectDir);
>> > >>>>>> console.log('hook.js: ' + hookApi.pluginDir);
>> > >>>>>> console.log('hook.js: ' + hookApi.cmdLine);}
>> > >>>>>
>> > >>>>> Make it easier to pass other stuff in the future & using a
>> > >>>>> sandoxed hookApi object.
>> > >>
>> >
>>
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
I've just sent a PR with unified hooks implementation for both cordova app and plugins developers. Please review
https://github.com/apache/cordova-lib/pull/55
More details
https://github.com/MSOpenTech/cordova-lib/commit/952690b7d7b42962b4e246c2b84c309846bf8750?short_path=8c918a9#diff-8c918a9f452feb5e3ef3339749806fc3
* Hooks can be defined in .cordova/hooks/hook_type, hooks/hook_type directories, config.xml (by application developers) and plugins/.../plugin.xml (by plugins developers)
* Javascript hooks retrieved from config.xml and plugins/.../plugin.xml will be run via new module loader with special Context argument passed. This object represents current hook script execution context including hook type, cordova version, paths, plugin info and other special utility modules.
* Introduced before_plugin_install, after_plugin_install and before_plugin_uninstall hooks.
Thx!
Sergey
-----Original Message-----
From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
Sent: Friday, May 16, 2014 4:08 AM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
Addressed code review notes, added spec tests, moved to cordova-lib repo.
https://github.com/apache/cordova-lib/pull/12
Thx!
Sergey
-----Original Message-----
From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
Sent: Wednesday, April 30, 2014 2:08 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
Updated code as per latest notes. Do we ready to merge this?
https://github.com/apache/cordova-plugman/pull/74
Thx!
Sergey
-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Tuesday, April 22, 2014 10:39 AM
To: dev
Subject: Re: Proposal: hooks support for plugins
Passing in a reference is not a bad idea, though that implies that there is a single top-level `cordova` object to reference. Not sure if thats the plan so far.. though it could be.
Probably easier to just support require() of cordova bits, but I'm not sure how to get that to work.
On Tue, Apr 22, 2014 at 1:32 PM, Brian LeRoux <b...@brian.io> wrote:
> shhh
>
>
> On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage
> <purplecabbage@gmail.com
> >wrote:
>
> > If you need a shell script, that can be easily hidden behind the
> > node module.
> >
> > Sent from my iPhone
> >
> > > On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > Maybe harsh but I'm in favor of abandoning shell scripts
> > > altogether and forcing modules as the way for hooks. Cross platform yada yada.
> > >
> > >
> > >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve
> > >> <ag...@chromium.org>
> > wrote:
> > >>
> > >> Very good point. Seen at least one other bug report that
> > >> struggled
> with
> > >> this use-case.
> > >>
> > >> I *think* hooks-as-a-module makes it easier.
> > >>
> > >> Just to be clear - I am also in favour of allowing hooks to be
> > >> npm
> > modules.
> > >> Possible there's use in continuing to support bash scripts as
> > >> hooks,
> but
> > >> there are definitely advantages to allowing modules.
> > >>
> > >>
> > >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny
> > >> <mm...@chromium.org>
> > >> wrote:
> > >>
> > >>> I was recently trying to solve a problem with hooks: how do I
> require()
> > >>> cordova itself? (I was trying to call "cordova plugin ls" and
> > >>> ended
> up
> > >>> just writing my own crude inline implementation instead). If
> > >>> the
> hooks
> > >>> themselves are being require()-ed, does it simplify that problem?
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <
> agrieve@chromium.org
> > >>>> wrote:
> > >>>
> > >>>> There are some *disadvantages* to not sub-shelling out for hooks:
> > >>>> - Harder to capture their stdio (certainly do-able though by
> swapping
> > >> out
> > >>>> system.std* for the duration of the hook)
> > >>>> - Harder to handle script failures (e.g. if they throw an
> > >>>> uncaught exception, we would like to be able to say "This hook script failed:
> > >>>> foo.js")
> > >>>> - Maybe this is doable, by storing a global
> > >>>> exception-was-thrown callback?
> > >>>> - Gives hooks the ability to mess up cordova's environment
> > >>>> (although
> > >>> maybe
> > >>>> the vm thing addresses this?)
> > >>>>
> > >>>> Would like to see tests for these things added before we launch
> > >>>> this feature.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > >>>> v-segreb@microsoft.com> wrote:
> > >>>>
> > >>>>> +1, I will name it as 'context'
> > >>>>>
> > >>>>> Thx!
> > >>>>> Sergey
> > >>>>> -----Original Message-----
> > >>>>> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > >>>>> Sent: Tuesday, April 22, 2014 7:34 AM
> > >>>>> To: dev@cordova.apache.org
> > >>>>> Subject: RE: Proposal: hooks support for plugins
> > >>>>>
> > >>>>>> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > >>>>>> module.exports = function(platform, projectDir, pluginDir,
> > >> cmdLine) {
> > >>>>>> console.log('hook.js: ' + platform);
> > >>>>>> console.log('hook.js: ' + projectDir);
> > >>>>>> console.log('hook.js: ' + pluginDir);
> > >>>>>> console.log('hook.js: ' + cmdLine);
> > >>>>>
> > >>>>> Personnaly prefer:
> > >>>>>
> > >>>>>> module.exports = function(hookApi) {
> > >>>>>> console.log('hook.js: ' + hookApi.platform);
> > >>>>>> console.log('hook.js: ' + hookApi.projectDir);
> > >>>>>> console.log('hook.js: ' + hookApi.pluginDir);
> > >>>>>> console.log('hook.js: ' + hookApi.cmdLine);}
> > >>>>>
> > >>>>> Make it easier to pass other stuff in the future & using a
> > >>>>> sandoxed hookApi object.
> > >>
> >
>
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
Addressed code review notes, added spec tests, moved to cordova-lib repo.
https://github.com/apache/cordova-lib/pull/12
Thx!
Sergey
-----Original Message-----
From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
Sent: Wednesday, April 30, 2014 2:08 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
Updated code as per latest notes. Do we ready to merge this?
https://github.com/apache/cordova-plugman/pull/74
Thx!
Sergey
-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Tuesday, April 22, 2014 10:39 AM
To: dev
Subject: Re: Proposal: hooks support for plugins
Passing in a reference is not a bad idea, though that implies that there is a single top-level `cordova` object to reference. Not sure if thats the plan so far.. though it could be.
Probably easier to just support require() of cordova bits, but I'm not sure how to get that to work.
On Tue, Apr 22, 2014 at 1:32 PM, Brian LeRoux <b...@brian.io> wrote:
> shhh
>
>
> On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage
> <purplecabbage@gmail.com
> >wrote:
>
> > If you need a shell script, that can be easily hidden behind the
> > node module.
> >
> > Sent from my iPhone
> >
> > > On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > Maybe harsh but I'm in favor of abandoning shell scripts
> > > altogether and forcing modules as the way for hooks. Cross platform yada yada.
> > >
> > >
> > >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve
> > >> <ag...@chromium.org>
> > wrote:
> > >>
> > >> Very good point. Seen at least one other bug report that
> > >> struggled
> with
> > >> this use-case.
> > >>
> > >> I *think* hooks-as-a-module makes it easier.
> > >>
> > >> Just to be clear - I am also in favour of allowing hooks to be
> > >> npm
> > modules.
> > >> Possible there's use in continuing to support bash scripts as
> > >> hooks,
> but
> > >> there are definitely advantages to allowing modules.
> > >>
> > >>
> > >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny
> > >> <mm...@chromium.org>
> > >> wrote:
> > >>
> > >>> I was recently trying to solve a problem with hooks: how do I
> require()
> > >>> cordova itself? (I was trying to call "cordova plugin ls" and
> > >>> ended
> up
> > >>> just writing my own crude inline implementation instead). If
> > >>> the
> hooks
> > >>> themselves are being require()-ed, does it simplify that problem?
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <
> agrieve@chromium.org
> > >>>> wrote:
> > >>>
> > >>>> There are some *disadvantages* to not sub-shelling out for hooks:
> > >>>> - Harder to capture their stdio (certainly do-able though by
> swapping
> > >> out
> > >>>> system.std* for the duration of the hook)
> > >>>> - Harder to handle script failures (e.g. if they throw an
> > >>>> uncaught exception, we would like to be able to say "This hook script failed:
> > >>>> foo.js")
> > >>>> - Maybe this is doable, by storing a global
> > >>>> exception-was-thrown callback?
> > >>>> - Gives hooks the ability to mess up cordova's environment
> > >>>> (although
> > >>> maybe
> > >>>> the vm thing addresses this?)
> > >>>>
> > >>>> Would like to see tests for these things added before we launch
> > >>>> this feature.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > >>>> v-segreb@microsoft.com> wrote:
> > >>>>
> > >>>>> +1, I will name it as 'context'
> > >>>>>
> > >>>>> Thx!
> > >>>>> Sergey
> > >>>>> -----Original Message-----
> > >>>>> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > >>>>> Sent: Tuesday, April 22, 2014 7:34 AM
> > >>>>> To: dev@cordova.apache.org
> > >>>>> Subject: RE: Proposal: hooks support for plugins
> > >>>>>
> > >>>>>> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > >>>>>> module.exports = function(platform, projectDir, pluginDir,
> > >> cmdLine) {
> > >>>>>> console.log('hook.js: ' + platform);
> > >>>>>> console.log('hook.js: ' + projectDir);
> > >>>>>> console.log('hook.js: ' + pluginDir);
> > >>>>>> console.log('hook.js: ' + cmdLine);
> > >>>>>
> > >>>>> Personnaly prefer:
> > >>>>>
> > >>>>>> module.exports = function(hookApi) {
> > >>>>>> console.log('hook.js: ' + hookApi.platform);
> > >>>>>> console.log('hook.js: ' + hookApi.projectDir);
> > >>>>>> console.log('hook.js: ' + hookApi.pluginDir);
> > >>>>>> console.log('hook.js: ' + hookApi.cmdLine);}
> > >>>>>
> > >>>>> Make it easier to pass other stuff in the future & using a
> > >>>>> sandoxed hookApi object.
> > >>
> >
>
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
Updated code as per latest notes. Do we ready to merge this?
https://github.com/apache/cordova-plugman/pull/74
Thx!
Sergey
-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Tuesday, April 22, 2014 10:39 AM
To: dev
Subject: Re: Proposal: hooks support for plugins
Passing in a reference is not a bad idea, though that implies that there is a single top-level `cordova` object to reference. Not sure if thats the plan so far.. though it could be.
Probably easier to just support require() of cordova bits, but I'm not sure how to get that to work.
On Tue, Apr 22, 2014 at 1:32 PM, Brian LeRoux <b...@brian.io> wrote:
> shhh
>
>
> On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage
> <purplecabbage@gmail.com
> >wrote:
>
> > If you need a shell script, that can be easily hidden behind the
> > node module.
> >
> > Sent from my iPhone
> >
> > > On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > Maybe harsh but I'm in favor of abandoning shell scripts
> > > altogether and forcing modules as the way for hooks. Cross platform yada yada.
> > >
> > >
> > >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve
> > >> <ag...@chromium.org>
> > wrote:
> > >>
> > >> Very good point. Seen at least one other bug report that
> > >> struggled
> with
> > >> this use-case.
> > >>
> > >> I *think* hooks-as-a-module makes it easier.
> > >>
> > >> Just to be clear - I am also in favour of allowing hooks to be
> > >> npm
> > modules.
> > >> Possible there's use in continuing to support bash scripts as
> > >> hooks,
> but
> > >> there are definitely advantages to allowing modules.
> > >>
> > >>
> > >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny
> > >> <mm...@chromium.org>
> > >> wrote:
> > >>
> > >>> I was recently trying to solve a problem with hooks: how do I
> require()
> > >>> cordova itself? (I was trying to call "cordova plugin ls" and
> > >>> ended
> up
> > >>> just writing my own crude inline implementation instead). If
> > >>> the
> hooks
> > >>> themselves are being require()-ed, does it simplify that problem?
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <
> agrieve@chromium.org
> > >>>> wrote:
> > >>>
> > >>>> There are some *disadvantages* to not sub-shelling out for hooks:
> > >>>> - Harder to capture their stdio (certainly do-able though by
> swapping
> > >> out
> > >>>> system.std* for the duration of the hook)
> > >>>> - Harder to handle script failures (e.g. if they throw an
> > >>>> uncaught exception, we would like to be able to say "This hook script failed:
> > >>>> foo.js")
> > >>>> - Maybe this is doable, by storing a global
> > >>>> exception-was-thrown callback?
> > >>>> - Gives hooks the ability to mess up cordova's environment
> > >>>> (although
> > >>> maybe
> > >>>> the vm thing addresses this?)
> > >>>>
> > >>>> Would like to see tests for these things added before we launch
> > >>>> this feature.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > >>>> v-segreb@microsoft.com> wrote:
> > >>>>
> > >>>>> +1, I will name it as 'context'
> > >>>>>
> > >>>>> Thx!
> > >>>>> Sergey
> > >>>>> -----Original Message-----
> > >>>>> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > >>>>> Sent: Tuesday, April 22, 2014 7:34 AM
> > >>>>> To: dev@cordova.apache.org
> > >>>>> Subject: RE: Proposal: hooks support for plugins
> > >>>>>
> > >>>>>> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > >>>>>> module.exports = function(platform, projectDir, pluginDir,
> > >> cmdLine) {
> > >>>>>> console.log('hook.js: ' + platform);
> > >>>>>> console.log('hook.js: ' + projectDir);
> > >>>>>> console.log('hook.js: ' + pluginDir);
> > >>>>>> console.log('hook.js: ' + cmdLine);
> > >>>>>
> > >>>>> Personnaly prefer:
> > >>>>>
> > >>>>>> module.exports = function(hookApi) {
> > >>>>>> console.log('hook.js: ' + hookApi.platform);
> > >>>>>> console.log('hook.js: ' + hookApi.projectDir);
> > >>>>>> console.log('hook.js: ' + hookApi.pluginDir);
> > >>>>>> console.log('hook.js: ' + hookApi.cmdLine);}
> > >>>>>
> > >>>>> Make it easier to pass other stuff in the future & using a
> > >>>>> sandoxed hookApi object.
> > >>
> >
>
Re: Proposal: hooks support for plugins
Posted by Michal Mocny <mm...@chromium.org>.
Passing in a reference is not a bad idea, though that implies that there is
a single top-level `cordova` object to reference. Not sure if thats the
plan so far.. though it could be.
Probably easier to just support require() of cordova bits, but I'm not sure
how to get that to work.
On Tue, Apr 22, 2014 at 1:32 PM, Brian LeRoux <b...@brian.io> wrote:
> shhh
>
>
> On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage <purplecabbage@gmail.com
> >wrote:
>
> > If you need a shell script, that can be easily hidden behind the node
> > module.
> >
> > Sent from my iPhone
> >
> > > On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > Maybe harsh but I'm in favor of abandoning shell scripts altogether and
> > > forcing modules as the way for hooks. Cross platform yada yada.
> > >
> > >
> > >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > >>
> > >> Very good point. Seen at least one other bug report that struggled
> with
> > >> this use-case.
> > >>
> > >> I *think* hooks-as-a-module makes it easier.
> > >>
> > >> Just to be clear - I am also in favour of allowing hooks to be npm
> > modules.
> > >> Possible there's use in continuing to support bash scripts as hooks,
> but
> > >> there are definitely advantages to allowing modules.
> > >>
> > >>
> > >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny <mm...@chromium.org>
> > >> wrote:
> > >>
> > >>> I was recently trying to solve a problem with hooks: how do I
> require()
> > >>> cordova itself? (I was trying to call "cordova plugin ls" and ended
> up
> > >>> just writing my own crude inline implementation instead). If the
> hooks
> > >>> themselves are being require()-ed, does it simplify that problem?
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <
> agrieve@chromium.org
> > >>>> wrote:
> > >>>
> > >>>> There are some *disadvantages* to not sub-shelling out for hooks:
> > >>>> - Harder to capture their stdio (certainly do-able though by
> swapping
> > >> out
> > >>>> system.std* for the duration of the hook)
> > >>>> - Harder to handle script failures (e.g. if they throw an uncaught
> > >>>> exception, we would like to be able to say "This hook script failed:
> > >>>> foo.js")
> > >>>> - Maybe this is doable, by storing a global exception-was-thrown
> > >>>> callback?
> > >>>> - Gives hooks the ability to mess up cordova's environment (although
> > >>> maybe
> > >>>> the vm thing addresses this?)
> > >>>>
> > >>>> Would like to see tests for these things added before we launch this
> > >>>> feature.
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > >>>> v-segreb@microsoft.com> wrote:
> > >>>>
> > >>>>> +1, I will name it as 'context'
> > >>>>>
> > >>>>> Thx!
> > >>>>> Sergey
> > >>>>> -----Original Message-----
> > >>>>> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > >>>>> Sent: Tuesday, April 22, 2014 7:34 AM
> > >>>>> To: dev@cordova.apache.org
> > >>>>> Subject: RE: Proposal: hooks support for plugins
> > >>>>>
> > >>>>>> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > >>>>>> module.exports = function(platform, projectDir, pluginDir,
> > >> cmdLine) {
> > >>>>>> console.log('hook.js: ' + platform);
> > >>>>>> console.log('hook.js: ' + projectDir);
> > >>>>>> console.log('hook.js: ' + pluginDir);
> > >>>>>> console.log('hook.js: ' + cmdLine);
> > >>>>>
> > >>>>> Personnaly prefer:
> > >>>>>
> > >>>>>> module.exports = function(hookApi) {
> > >>>>>> console.log('hook.js: ' + hookApi.platform);
> > >>>>>> console.log('hook.js: ' + hookApi.projectDir);
> > >>>>>> console.log('hook.js: ' + hookApi.pluginDir);
> > >>>>>> console.log('hook.js: ' + hookApi.cmdLine);}
> > >>>>>
> > >>>>> Make it easier to pass other stuff in the future & using a sandoxed
> > >>>>> hookApi object.
> > >>
> >
>
Re: Proposal: hooks support for plugins
Posted by Brian LeRoux <b...@brian.io>.
shhh
On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage <pu...@gmail.com>wrote:
> If you need a shell script, that can be easily hidden behind the node
> module.
>
> Sent from my iPhone
>
> > On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > Maybe harsh but I'm in favor of abandoning shell scripts altogether and
> > forcing modules as the way for hooks. Cross platform yada yada.
> >
> >
> >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
> >>
> >> Very good point. Seen at least one other bug report that struggled with
> >> this use-case.
> >>
> >> I *think* hooks-as-a-module makes it easier.
> >>
> >> Just to be clear - I am also in favour of allowing hooks to be npm
> modules.
> >> Possible there's use in continuing to support bash scripts as hooks, but
> >> there are definitely advantages to allowing modules.
> >>
> >>
> >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >>
> >>> I was recently trying to solve a problem with hooks: how do I require()
> >>> cordova itself? (I was trying to call "cordova plugin ls" and ended up
> >>> just writing my own crude inline implementation instead). If the hooks
> >>> themselves are being require()-ed, does it simplify that problem?
> >>>
> >>> -Michal
> >>>
> >>>
> >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <agrieve@chromium.org
> >>>> wrote:
> >>>
> >>>> There are some *disadvantages* to not sub-shelling out for hooks:
> >>>> - Harder to capture their stdio (certainly do-able though by swapping
> >> out
> >>>> system.std* for the duration of the hook)
> >>>> - Harder to handle script failures (e.g. if they throw an uncaught
> >>>> exception, we would like to be able to say "This hook script failed:
> >>>> foo.js")
> >>>> - Maybe this is doable, by storing a global exception-was-thrown
> >>>> callback?
> >>>> - Gives hooks the ability to mess up cordova's environment (although
> >>> maybe
> >>>> the vm thing addresses this?)
> >>>>
> >>>> Would like to see tests for these things added before we launch this
> >>>> feature.
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> >>>> v-segreb@microsoft.com> wrote:
> >>>>
> >>>>> +1, I will name it as 'context'
> >>>>>
> >>>>> Thx!
> >>>>> Sergey
> >>>>> -----Original Message-----
> >>>>> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> >>>>> Sent: Tuesday, April 22, 2014 7:34 AM
> >>>>> To: dev@cordova.apache.org
> >>>>> Subject: RE: Proposal: hooks support for plugins
> >>>>>
> >>>>>> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> >>>>>> module.exports = function(platform, projectDir, pluginDir,
> >> cmdLine) {
> >>>>>> console.log('hook.js: ' + platform);
> >>>>>> console.log('hook.js: ' + projectDir);
> >>>>>> console.log('hook.js: ' + pluginDir);
> >>>>>> console.log('hook.js: ' + cmdLine);
> >>>>>
> >>>>> Personnaly prefer:
> >>>>>
> >>>>>> module.exports = function(hookApi) {
> >>>>>> console.log('hook.js: ' + hookApi.platform);
> >>>>>> console.log('hook.js: ' + hookApi.projectDir);
> >>>>>> console.log('hook.js: ' + hookApi.pluginDir);
> >>>>>> console.log('hook.js: ' + hookApi.cmdLine);}
> >>>>>
> >>>>> Make it easier to pass other stuff in the future & using a sandoxed
> >>>>> hookApi object.
> >>
>
Re: Proposal: hooks support for plugins
Posted by purplecabbage <pu...@gmail.com>.
If you need a shell script, that can be easily hidden behind the node module.
Sent from my iPhone
> On Apr 22, 2014, at 9:34 AM, Brian LeRoux <b...@brian.io> wrote:
>
> Maybe harsh but I'm in favor of abandoning shell scripts altogether and
> forcing modules as the way for hooks. Cross platform yada yada.
>
>
>> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve <ag...@chromium.org> wrote:
>>
>> Very good point. Seen at least one other bug report that struggled with
>> this use-case.
>>
>> I *think* hooks-as-a-module makes it easier.
>>
>> Just to be clear - I am also in favour of allowing hooks to be npm modules.
>> Possible there's use in continuing to support bash scripts as hooks, but
>> there are definitely advantages to allowing modules.
>>
>>
>> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny <mm...@chromium.org>
>> wrote:
>>
>>> I was recently trying to solve a problem with hooks: how do I require()
>>> cordova itself? (I was trying to call "cordova plugin ls" and ended up
>>> just writing my own crude inline implementation instead). If the hooks
>>> themselves are being require()-ed, does it simplify that problem?
>>>
>>> -Michal
>>>
>>>
>>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <agrieve@chromium.org
>>>> wrote:
>>>
>>>> There are some *disadvantages* to not sub-shelling out for hooks:
>>>> - Harder to capture their stdio (certainly do-able though by swapping
>> out
>>>> system.std* for the duration of the hook)
>>>> - Harder to handle script failures (e.g. if they throw an uncaught
>>>> exception, we would like to be able to say "This hook script failed:
>>>> foo.js")
>>>> - Maybe this is doable, by storing a global exception-was-thrown
>>>> callback?
>>>> - Gives hooks the ability to mess up cordova's environment (although
>>> maybe
>>>> the vm thing addresses this?)
>>>>
>>>> Would like to see tests for these things added before we launch this
>>>> feature.
>>>>
>>>>
>>>>
>>>> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
>>>> v-segreb@microsoft.com> wrote:
>>>>
>>>>> +1, I will name it as 'context'
>>>>>
>>>>> Thx!
>>>>> Sergey
>>>>> -----Original Message-----
>>>>> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
>>>>> Sent: Tuesday, April 22, 2014 7:34 AM
>>>>> To: dev@cordova.apache.org
>>>>> Subject: RE: Proposal: hooks support for plugins
>>>>>
>>>>>> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
>>>>>> module.exports = function(platform, projectDir, pluginDir,
>> cmdLine) {
>>>>>> console.log('hook.js: ' + platform);
>>>>>> console.log('hook.js: ' + projectDir);
>>>>>> console.log('hook.js: ' + pluginDir);
>>>>>> console.log('hook.js: ' + cmdLine);
>>>>>
>>>>> Personnaly prefer:
>>>>>
>>>>>> module.exports = function(hookApi) {
>>>>>> console.log('hook.js: ' + hookApi.platform);
>>>>>> console.log('hook.js: ' + hookApi.projectDir);
>>>>>> console.log('hook.js: ' + hookApi.pluginDir);
>>>>>> console.log('hook.js: ' + hookApi.cmdLine);}
>>>>>
>>>>> Make it easier to pass other stuff in the future & using a sandoxed
>>>>> hookApi object.
>>
Re: Proposal: hooks support for plugins
Posted by Brian LeRoux <b...@brian.io>.
Maybe harsh but I'm in favor of abandoning shell scripts altogether and
forcing modules as the way for hooks. Cross platform yada yada.
On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Very good point. Seen at least one other bug report that struggled with
> this use-case.
>
> I *think* hooks-as-a-module makes it easier.
>
> Just to be clear - I am also in favour of allowing hooks to be npm modules.
> Possible there's use in continuing to support bash scripts as hooks, but
> there are definitely advantages to allowing modules.
>
>
> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > I was recently trying to solve a problem with hooks: how do I require()
> > cordova itself? (I was trying to call "cordova plugin ls" and ended up
> > just writing my own crude inline implementation instead). If the hooks
> > themselves are being require()-ed, does it simplify that problem?
> >
> > -Michal
> >
> >
> > On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > There are some *disadvantages* to not sub-shelling out for hooks:
> > > - Harder to capture their stdio (certainly do-able though by swapping
> out
> > > system.std* for the duration of the hook)
> > > - Harder to handle script failures (e.g. if they throw an uncaught
> > > exception, we would like to be able to say "This hook script failed:
> > > foo.js")
> > > - Maybe this is doable, by storing a global exception-was-thrown
> > > callback?
> > > - Gives hooks the ability to mess up cordova's environment (although
> > maybe
> > > the vm thing addresses this?)
> > >
> > > Would like to see tests for these things added before we launch this
> > > feature.
> > >
> > >
> > >
> > > On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > > v-segreb@microsoft.com> wrote:
> > >
> > > > +1, I will name it as 'context'
> > > >
> > > > Thx!
> > > > Sergey
> > > > -----Original Message-----
> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > > > Sent: Tuesday, April 22, 2014 7:34 AM
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: Proposal: hooks support for plugins
> > > >
> > > > On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > > > > module.exports = function(platform, projectDir, pluginDir,
> cmdLine) {
> > > > > console.log('hook.js: ' + platform);
> > > > > console.log('hook.js: ' + projectDir);
> > > > > console.log('hook.js: ' + pluginDir);
> > > > > console.log('hook.js: ' + cmdLine);
> > > > >
> > > >
> > > > Personnaly prefer:
> > > >
> > > > > module.exports = function(hookApi) {
> > > > > console.log('hook.js: ' + hookApi.platform);
> > > > > console.log('hook.js: ' + hookApi.projectDir);
> > > > > console.log('hook.js: ' + hookApi.pluginDir);
> > > > > console.log('hook.js: ' + hookApi.cmdLine);}
> > > >
> > > > Make it easier to pass other stuff in the future & using a sandoxed
> > > > hookApi object.
> > > >
> > > >
> > > >
> > >
> >
>
Re: Proposal: hooks support for plugins
Posted by Andrew Grieve <ag...@chromium.org>.
Very good point. Seen at least one other bug report that struggled with
this use-case.
I *think* hooks-as-a-module makes it easier.
Just to be clear - I am also in favour of allowing hooks to be npm modules.
Possible there's use in continuing to support bash scripts as hooks, but
there are definitely advantages to allowing modules.
On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny <mm...@chromium.org> wrote:
> I was recently trying to solve a problem with hooks: how do I require()
> cordova itself? (I was trying to call "cordova plugin ls" and ended up
> just writing my own crude inline implementation instead). If the hooks
> themselves are being require()-ed, does it simplify that problem?
>
> -Michal
>
>
> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > There are some *disadvantages* to not sub-shelling out for hooks:
> > - Harder to capture their stdio (certainly do-able though by swapping out
> > system.std* for the duration of the hook)
> > - Harder to handle script failures (e.g. if they throw an uncaught
> > exception, we would like to be able to say "This hook script failed:
> > foo.js")
> > - Maybe this is doable, by storing a global exception-was-thrown
> > callback?
> > - Gives hooks the ability to mess up cordova's environment (although
> maybe
> > the vm thing addresses this?)
> >
> > Would like to see tests for these things added before we launch this
> > feature.
> >
> >
> >
> > On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > v-segreb@microsoft.com> wrote:
> >
> > > +1, I will name it as 'context'
> > >
> > > Thx!
> > > Sergey
> > > -----Original Message-----
> > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > > Sent: Tuesday, April 22, 2014 7:34 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Proposal: hooks support for plugins
> > >
> > > On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > > > module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> > > > console.log('hook.js: ' + platform);
> > > > console.log('hook.js: ' + projectDir);
> > > > console.log('hook.js: ' + pluginDir);
> > > > console.log('hook.js: ' + cmdLine);
> > > >
> > >
> > > Personnaly prefer:
> > >
> > > > module.exports = function(hookApi) {
> > > > console.log('hook.js: ' + hookApi.platform);
> > > > console.log('hook.js: ' + hookApi.projectDir);
> > > > console.log('hook.js: ' + hookApi.pluginDir);
> > > > console.log('hook.js: ' + hookApi.cmdLine);}
> > >
> > > Make it easier to pass other stuff in the future & using a sandoxed
> > > hookApi object.
> > >
> > >
> > >
> >
>
Re: Proposal: hooks support for plugins
Posted by Michal Mocny <mm...@chromium.org>.
I was recently trying to solve a problem with hooks: how do I require()
cordova itself? (I was trying to call "cordova plugin ls" and ended up
just writing my own crude inline implementation instead). If the hooks
themselves are being require()-ed, does it simplify that problem?
-Michal
On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <ag...@chromium.org>wrote:
> There are some *disadvantages* to not sub-shelling out for hooks:
> - Harder to capture their stdio (certainly do-able though by swapping out
> system.std* for the duration of the hook)
> - Harder to handle script failures (e.g. if they throw an uncaught
> exception, we would like to be able to say "This hook script failed:
> foo.js")
> - Maybe this is doable, by storing a global exception-was-thrown
> callback?
> - Gives hooks the ability to mess up cordova's environment (although maybe
> the vm thing addresses this?)
>
> Would like to see tests for these things added before we launch this
> feature.
>
>
>
> On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> v-segreb@microsoft.com> wrote:
>
> > +1, I will name it as 'context'
> >
> > Thx!
> > Sergey
> > -----Original Message-----
> > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > Sent: Tuesday, April 22, 2014 7:34 AM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: hooks support for plugins
> >
> > On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > > module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> > > console.log('hook.js: ' + platform);
> > > console.log('hook.js: ' + projectDir);
> > > console.log('hook.js: ' + pluginDir);
> > > console.log('hook.js: ' + cmdLine);
> > >
> >
> > Personnaly prefer:
> >
> > > module.exports = function(hookApi) {
> > > console.log('hook.js: ' + hookApi.platform);
> > > console.log('hook.js: ' + hookApi.projectDir);
> > > console.log('hook.js: ' + hookApi.pluginDir);
> > > console.log('hook.js: ' + hookApi.cmdLine);}
> >
> > Make it easier to pass other stuff in the future & using a sandoxed
> > hookApi object.
> >
> >
> >
>
Re: Proposal: hooks support for plugins
Posted by Andrew Grieve <ag...@chromium.org>.
There are some *disadvantages* to not sub-shelling out for hooks:
- Harder to capture their stdio (certainly do-able though by swapping out
system.std* for the duration of the hook)
- Harder to handle script failures (e.g. if they throw an uncaught
exception, we would like to be able to say "This hook script failed:
foo.js")
- Maybe this is doable, by storing a global exception-was-thrown callback?
- Gives hooks the ability to mess up cordova's environment (although maybe
the vm thing addresses this?)
Would like to see tests for these things added before we launch this
feature.
On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
v-segreb@microsoft.com> wrote:
> +1, I will name it as 'context'
>
> Thx!
> Sergey
> -----Original Message-----
> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> Sent: Tuesday, April 22, 2014 7:34 AM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: hooks support for plugins
>
> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> > console.log('hook.js: ' + platform);
> > console.log('hook.js: ' + projectDir);
> > console.log('hook.js: ' + pluginDir);
> > console.log('hook.js: ' + cmdLine);
> >
>
> Personnaly prefer:
>
> > module.exports = function(hookApi) {
> > console.log('hook.js: ' + hookApi.platform);
> > console.log('hook.js: ' + hookApi.projectDir);
> > console.log('hook.js: ' + hookApi.pluginDir);
> > console.log('hook.js: ' + hookApi.cmdLine);}
>
> Make it easier to pass other stuff in the future & using a sandoxed
> hookApi object.
>
>
>
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
+1, I will name it as 'context'
Thx!
Sergey
-----Original Message-----
From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
Sent: Tuesday, April 22, 2014 7:34 AM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> console.log('hook.js: ' + platform);
> console.log('hook.js: ' + projectDir);
> console.log('hook.js: ' + pluginDir);
> console.log('hook.js: ' + cmdLine);
>
Personnaly prefer:
> module.exports = function(hookApi) {
> console.log('hook.js: ' + hookApi.platform);
> console.log('hook.js: ' + hookApi.projectDir);
> console.log('hook.js: ' + hookApi.pluginDir);
> console.log('hook.js: ' + hookApi.cmdLine);}
Make it easier to pass other stuff in the future & using a sandoxed hookApi object.
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> console.log('hook.js: ' + platform);
> console.log('hook.js: ' + projectDir);
> console.log('hook.js: ' + pluginDir);
> console.log('hook.js: ' + cmdLine);
>
Personnaly prefer:
> module.exports = function(hookApi) {
> console.log('hook.js: ' + hookApi.platform);
> console.log('hook.js: ' + hookApi.projectDir);
> console.log('hook.js: ' + hookApi.pluginDir);
> console.log('hook.js: ' + hookApi.cmdLine);}
Make it easier to pass other stuff in the future & using a sandoxed hookApi object.
Re: Proposal: hooks support for plugins
Posted by Jesse <pu...@gmail.com>.
Looks good Sergey, I like this approach.
I also agree with Parash's statements, I think we should consider plugin
hook sandboxing out of scope.
@purplecabbage
risingj.com
On Mon, Apr 21, 2014 at 12:39 PM, Sergey Grebnov (Akvelon) <
v-segreb@microsoft.com> wrote:
> Updated PR: https://github.com/apache/cordova-plugman/pull/74
>
> 1. Created issue CB-6481 to cover this work.
> 2. Switched to nodejs module loader. Sample hook file implementation with
> async functionality:
>
> var Q = require('./q');
>
> module.exports = function(platform, projectDir, pluginDir, cmdLine) {
> console.log('hook.js: ' + platform);
> console.log('hook.js: ' + projectDir);
> console.log('hook.js: ' + pluginDir);
> console.log('hook.js: ' + cmdLine);
>
> var deferral = new Q.defer();
>
> setTimeout(function(){
> deferral.resolve();
> }, 1000);
>
> return deferral.promise;
> }
>
> Thx!!
> Sergey
>
> -----Original Message-----
> From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panarasi@microsoft.com]
> Sent: Friday, April 18, 2014 12:30 PM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: hooks support for plugins
>
> As you rightly pointed out, this proposal is very similar to npm modules,
> where modules get full access as the hosting code. IMHO, the problem of
> sandboxing may not be specific to Cordova and I am not sure if we could
> solve it for the Cordova/Plugman CLI without creating an really complex
> system. For example, we may not have to stop just with Sandboxing files, we
> would even want to sandbox sockets, child_process and other core node
> capabilities as well.
> If we do create such a sandbox model, should it not be a separate system
> that can be used by other "module-loaders" as well? CordovaCLI can be yet
> another consumer of this sandbox.
>
> -----Original Message-----
> From: Shazron [mailto:shazron@gmail.com]
> Sent: Friday, April 18, 2014 11:16 AM
> To: dev@cordova.apache.org
> Subject: Re: Proposal: hooks support for plugins
>
> Sorry for the flurry of emails, found a proof of concept for overriding
> the filesystem core api, using nodejs vm:
> https://github.com/augustl/nodejs-sandboxed-fs
>
>
> On Fri, Apr 18, 2014 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
>
> > Just food for thought for the future, regarding trust for these
> > scripts, based on the discussion so far:
> >
> > 1. Security model is basically what npm's security model for scripts
> > are (full trust) 2. We could manually "verify" the scripts (for each
> > update! gets tedious), but before it is verified, there is a banner in
> > the plugin registry. Not sure how this works with command line adding
> > of plugins with scripts, and dependencies, since users will not see
> > that banner, and if we have a text warning with confirmation, that
> > gets annoying.
> > 3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure
> > exactly how (haven't investigated fully).
> >
> > I think the ideal situation is to:
> > 1. sandbox filesystem reads to the project folder only 2. sandbox
> > filesystem writes to the project folder only 3. prevent the plugin
> > from executing scripts that either exist or are have been created in
> > the project folder
> >
> > Not sure how to do this yet though (how to override the node
> > filesystem core api temporarily).
> >
> >
> >
> >
> > On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> yes! (ideally we kill magic folders and make this explicit in the
> >> config)
> >>
> >>
> >> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) <
> >> v-segreb@microsoft.com> wrote:
> >>
> >> > Sound like most of us prefer module.export. Cool, will update the
> >> > code today and let you know once this is done.
> >> >
> >> > Since we will be moving to cordova-lib the next action item here
> >> > could
> >> be
> >> > creating uniform hooks with shared code for both application level
> >> > and plugin level hooks. Thoughts?
> >> >
> >> > Thx!
> >> > Sergey
> >> > -----Original Message-----
> >> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On
> >> > Behalf
> >> Of
> >> > Brian LeRoux
> >> > Sent: Friday, April 18, 2014 8:25 AM
> >> > To: dev@cordova.apache.org
> >> > Subject: Re: Proposal: hooks support for plugins
> >> >
> >> > like this too / would be much cleaner
> >> >
> >> >
> >> >
> >> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
> >> >
> >> > > I like Parashuram's idea. This way the plugin hooks can be
> >> > > testable as well?
> >> > >
> >> > >
> >> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN
> >> > > TECH) < panarasi@microsoft.com> wrote:
> >> > >
> >> > > > Currently, the plugin hooks are constructed like the hooks in a
> >> > > > cordova project. An alternative would be to construct the
> >> > > > javascript files to
> >> > > have
> >> > > > module.exports, and we could pass in the parameters to the
> >> > > > function that
> >> > > is
> >> > > > exported. This way, the module will not spawn a new node process.
> >> > > > Comments, Thoughts?
> >> > > >
> >> > > > -----Original Message-----
> >> > > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> >> > > > Sent: Thursday, April 17, 2014 5:19 PM
> >> > > > To: dev@cordova.apache.org
> >> > > > Subject: RE: Proposal: hooks support for plugins
> >> > > >
> >> > > > I've sent a pull request with initial implementation for review.
> >> > > > https://github.com/apache/cordova-plugman/pull/74
> >> > > >
> >> > > > Thx!
> >> > > > Sergey
> >> > > > -----Original Message-----
> >> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> >> > > > Sent: Thursday, March 6, 2014 2:07 PM
> >> > > > To: dev@cordova.apache.org
> >> > > > Subject: RE: Proposal: hooks support for plugins
> >> > > >
> >> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> >> > > > > Can we think about scripts as just a new plugin module? -
> >> > > > > Similar to js-module or config-file and which must be
> >> > > > > processed special way (by execution).
> >> > > > >
> >> > > > > <script-module src="src/compile_sqlite.js"/> <framework
> >> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
> >> > > > > <script-module src="src/add_win8_toastCapable.js"/>
> >> > > > > <script-module src="src/set_default_target_paltform_arm.js"/>
> >> > > > >
> >> > > > > Not so powerful and cool, but easy to implement and understand.
> >> > > > > During uninstall each script is called again but with
> 'uninstall'
> >> > > > > flag (or each script file can emit install and uninstall
> >> > > > > functions)
> >> > > > >
> >> > > >
> >> > > > I'm all for simple, what happens if one of those scripts fails?
> E.g.
> >> > > > failed compile
> >> > > >
> >> > > > For example in cli:
> >> > > >
> >> > > > cordova plugin add sqlite
> >> > > > platforms = ['android', 'windows8']; for(p in platforms)
> >> > > > installPlugin('sqlite'); // android ok! windows8 fails at
> >> > > > 'src/compile_sqlite.js'
> >> > > >
> >> > > > Is 'sqlite' at that point installed on android? Do we rollback
> >> > > > the install? Run the uninstall() scripts?
> >> > > >
> >> > > > For that reason, sandbox idea seems less chaotic with some
> >> > > > hookApi -
> >> > > which
> >> > > > would cleanup properly if something goes wrong...
> >> > > >
> >> > > > What you're suggesting seems like it could work, until
> >> > > > something goes wrong and leaves the platform(s) project/native
> >> > > > in an
> >> > inconsistent state.
> >> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
> >> > > >
> >> > > > Could be doable but not sure well it would work.
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
Updated PR: https://github.com/apache/cordova-plugman/pull/74
1. Created issue CB-6481 to cover this work.
2. Switched to nodejs module loader. Sample hook file implementation with async functionality:
var Q = require('./q');
module.exports = function(platform, projectDir, pluginDir, cmdLine) {
console.log('hook.js: ' + platform);
console.log('hook.js: ' + projectDir);
console.log('hook.js: ' + pluginDir);
console.log('hook.js: ' + cmdLine);
var deferral = new Q.defer();
setTimeout(function(){
deferral.resolve();
}, 1000);
return deferral.promise;
}
Thx!!
Sergey
-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panarasi@microsoft.com]
Sent: Friday, April 18, 2014 12:30 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
As you rightly pointed out, this proposal is very similar to npm modules, where modules get full access as the hosting code. IMHO, the problem of sandboxing may not be specific to Cordova and I am not sure if we could solve it for the Cordova/Plugman CLI without creating an really complex system. For example, we may not have to stop just with Sandboxing files, we would even want to sandbox sockets, child_process and other core node capabilities as well.
If we do create such a sandbox model, should it not be a separate system that can be used by other "module-loaders" as well? CordovaCLI can be yet another consumer of this sandbox.
-----Original Message-----
From: Shazron [mailto:shazron@gmail.com]
Sent: Friday, April 18, 2014 11:16 AM
To: dev@cordova.apache.org
Subject: Re: Proposal: hooks support for plugins
Sorry for the flurry of emails, found a proof of concept for overriding the filesystem core api, using nodejs vm:
https://github.com/augustl/nodejs-sandboxed-fs
On Fri, Apr 18, 2014 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
> Just food for thought for the future, regarding trust for these
> scripts, based on the discussion so far:
>
> 1. Security model is basically what npm's security model for scripts
> are (full trust) 2. We could manually "verify" the scripts (for each
> update! gets tedious), but before it is verified, there is a banner in
> the plugin registry. Not sure how this works with command line adding
> of plugins with scripts, and dependencies, since users will not see
> that banner, and if we have a text warning with confirmation, that
> gets annoying.
> 3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure
> exactly how (haven't investigated fully).
>
> I think the ideal situation is to:
> 1. sandbox filesystem reads to the project folder only 2. sandbox
> filesystem writes to the project folder only 3. prevent the plugin
> from executing scripts that either exist or are have been created in
> the project folder
>
> Not sure how to do this yet though (how to override the node
> filesystem core api temporarily).
>
>
>
>
> On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> yes! (ideally we kill magic folders and make this explicit in the
>> config)
>>
>>
>> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) <
>> v-segreb@microsoft.com> wrote:
>>
>> > Sound like most of us prefer module.export. Cool, will update the
>> > code today and let you know once this is done.
>> >
>> > Since we will be moving to cordova-lib the next action item here
>> > could
>> be
>> > creating uniform hooks with shared code for both application level
>> > and plugin level hooks. Thoughts?
>> >
>> > Thx!
>> > Sergey
>> > -----Original Message-----
>> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On
>> > Behalf
>> Of
>> > Brian LeRoux
>> > Sent: Friday, April 18, 2014 8:25 AM
>> > To: dev@cordova.apache.org
>> > Subject: Re: Proposal: hooks support for plugins
>> >
>> > like this too / would be much cleaner
>> >
>> >
>> >
>> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > I like Parashuram's idea. This way the plugin hooks can be
>> > > testable as well?
>> > >
>> > >
>> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN
>> > > TECH) < panarasi@microsoft.com> wrote:
>> > >
>> > > > Currently, the plugin hooks are constructed like the hooks in a
>> > > > cordova project. An alternative would be to construct the
>> > > > javascript files to
>> > > have
>> > > > module.exports, and we could pass in the parameters to the
>> > > > function that
>> > > is
>> > > > exported. This way, the module will not spawn a new node process.
>> > > > Comments, Thoughts?
>> > > >
>> > > > -----Original Message-----
>> > > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
>> > > > Sent: Thursday, April 17, 2014 5:19 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > I've sent a pull request with initial implementation for review.
>> > > > https://github.com/apache/cordova-plugman/pull/74
>> > > >
>> > > > Thx!
>> > > > Sergey
>> > > > -----Original Message-----
>> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
>> > > > Sent: Thursday, March 6, 2014 2:07 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
>> > > > > Can we think about scripts as just a new plugin module? -
>> > > > > Similar to js-module or config-file and which must be
>> > > > > processed special way (by execution).
>> > > > >
>> > > > > <script-module src="src/compile_sqlite.js"/> <framework
>> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
>> > > > > <script-module src="src/add_win8_toastCapable.js"/>
>> > > > > <script-module src="src/set_default_target_paltform_arm.js"/>
>> > > > >
>> > > > > Not so powerful and cool, but easy to implement and understand.
>> > > > > During uninstall each script is called again but with 'uninstall'
>> > > > > flag (or each script file can emit install and uninstall
>> > > > > functions)
>> > > > >
>> > > >
>> > > > I'm all for simple, what happens if one of those scripts fails? E.g.
>> > > > failed compile
>> > > >
>> > > > For example in cli:
>> > > >
>> > > > cordova plugin add sqlite
>> > > > platforms = ['android', 'windows8']; for(p in platforms)
>> > > > installPlugin('sqlite'); // android ok! windows8 fails at
>> > > > 'src/compile_sqlite.js'
>> > > >
>> > > > Is 'sqlite' at that point installed on android? Do we rollback
>> > > > the install? Run the uninstall() scripts?
>> > > >
>> > > > For that reason, sandbox idea seems less chaotic with some
>> > > > hookApi -
>> > > which
>> > > > would cleanup properly if something goes wrong...
>> > > >
>> > > > What you're suggesting seems like it could work, until
>> > > > something goes wrong and leaves the platform(s) project/native
>> > > > in an
>> > inconsistent state.
>> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
>> > > >
>> > > > Could be doable but not sure well it would work.
>> > > >
>> > > >
>> > >
>> >
>>
>
>
RE: Proposal: hooks support for plugins
Posted by "Parashuram Narasimhan (MS OPEN TECH)" <pa...@microsoft.com>.
As you rightly pointed out, this proposal is very similar to npm modules, where modules get full access as the hosting code. IMHO, the problem of sandboxing may not be specific to Cordova and I am not sure if we could solve it for the Cordova/Plugman CLI without creating an really complex system. For example, we may not have to stop just with Sandboxing files, we would even want to sandbox sockets, child_process and other core node capabilities as well.
If we do create such a sandbox model, should it not be a separate system that can be used by other "module-loaders" as well? CordovaCLI can be yet another consumer of this sandbox.
-----Original Message-----
From: Shazron [mailto:shazron@gmail.com]
Sent: Friday, April 18, 2014 11:16 AM
To: dev@cordova.apache.org
Subject: Re: Proposal: hooks support for plugins
Sorry for the flurry of emails, found a proof of concept for overriding the filesystem core api, using nodejs vm:
https://github.com/augustl/nodejs-sandboxed-fs
On Fri, Apr 18, 2014 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
> Just food for thought for the future, regarding trust for these
> scripts, based on the discussion so far:
>
> 1. Security model is basically what npm's security model for scripts
> are (full trust) 2. We could manually "verify" the scripts (for each
> update! gets tedious), but before it is verified, there is a banner in
> the plugin registry. Not sure how this works with command line adding
> of plugins with scripts, and dependencies, since users will not see
> that banner, and if we have a text warning with confirmation, that
> gets annoying.
> 3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure
> exactly how (haven't investigated fully).
>
> I think the ideal situation is to:
> 1. sandbox filesystem reads to the project folder only 2. sandbox
> filesystem writes to the project folder only 3. prevent the plugin
> from executing scripts that either exist or are have been created in
> the project folder
>
> Not sure how to do this yet though (how to override the node
> filesystem core api temporarily).
>
>
>
>
> On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> yes! (ideally we kill magic folders and make this explicit in the
>> config)
>>
>>
>> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) <
>> v-segreb@microsoft.com> wrote:
>>
>> > Sound like most of us prefer module.export. Cool, will update the
>> > code today and let you know once this is done.
>> >
>> > Since we will be moving to cordova-lib the next action item here
>> > could
>> be
>> > creating uniform hooks with shared code for both application level
>> > and plugin level hooks. Thoughts?
>> >
>> > Thx!
>> > Sergey
>> > -----Original Message-----
>> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On
>> > Behalf
>> Of
>> > Brian LeRoux
>> > Sent: Friday, April 18, 2014 8:25 AM
>> > To: dev@cordova.apache.org
>> > Subject: Re: Proposal: hooks support for plugins
>> >
>> > like this too / would be much cleaner
>> >
>> >
>> >
>> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > I like Parashuram's idea. This way the plugin hooks can be
>> > > testable as well?
>> > >
>> > >
>> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN
>> > > TECH) < panarasi@microsoft.com> wrote:
>> > >
>> > > > Currently, the plugin hooks are constructed like the hooks in a
>> > > > cordova project. An alternative would be to construct the
>> > > > javascript files to
>> > > have
>> > > > module.exports, and we could pass in the parameters to the
>> > > > function that
>> > > is
>> > > > exported. This way, the module will not spawn a new node process.
>> > > > Comments, Thoughts?
>> > > >
>> > > > -----Original Message-----
>> > > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
>> > > > Sent: Thursday, April 17, 2014 5:19 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > I've sent a pull request with initial implementation for review.
>> > > > https://github.com/apache/cordova-plugman/pull/74
>> > > >
>> > > > Thx!
>> > > > Sergey
>> > > > -----Original Message-----
>> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
>> > > > Sent: Thursday, March 6, 2014 2:07 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
>> > > > > Can we think about scripts as just a new plugin module? -
>> > > > > Similar to js-module or config-file and which must be
>> > > > > processed special way (by execution).
>> > > > >
>> > > > > <script-module src="src/compile_sqlite.js"/> <framework
>> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
>> > > > > <script-module src="src/add_win8_toastCapable.js"/>
>> > > > > <script-module src="src/set_default_target_paltform_arm.js"/>
>> > > > >
>> > > > > Not so powerful and cool, but easy to implement and understand.
>> > > > > During uninstall each script is called again but with 'uninstall'
>> > > > > flag (or each script file can emit install and uninstall
>> > > > > functions)
>> > > > >
>> > > >
>> > > > I'm all for simple, what happens if one of those scripts fails? E.g.
>> > > > failed compile
>> > > >
>> > > > For example in cli:
>> > > >
>> > > > cordova plugin add sqlite
>> > > > platforms = ['android', 'windows8']; for(p in platforms)
>> > > > installPlugin('sqlite'); // android ok! windows8 fails at
>> > > > 'src/compile_sqlite.js'
>> > > >
>> > > > Is 'sqlite' at that point installed on android? Do we rollback
>> > > > the install? Run the uninstall() scripts?
>> > > >
>> > > > For that reason, sandbox idea seems less chaotic with some
>> > > > hookApi -
>> > > which
>> > > > would cleanup properly if something goes wrong...
>> > > >
>> > > > What you're suggesting seems like it could work, until
>> > > > something goes wrong and leaves the platform(s) project/native
>> > > > in an
>> > inconsistent state.
>> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
>> > > >
>> > > > Could be doable but not sure well it would work.
>> > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Proposal: hooks support for plugins
Posted by Shazron <sh...@gmail.com>.
Sorry for the flurry of emails, found a proof of concept for overriding the
filesystem core api, using nodejs vm:
https://github.com/augustl/nodejs-sandboxed-fs
On Fri, Apr 18, 2014 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
> Just food for thought for the future, regarding trust for these scripts,
> based on the discussion so far:
>
> 1. Security model is basically what npm's security model for scripts are
> (full trust)
> 2. We could manually "verify" the scripts (for each update! gets tedious),
> but before it is verified, there is a banner in the plugin registry. Not
> sure how this works with command line adding of plugins with scripts, and
> dependencies, since users will not see that banner, and if we have a text
> warning with confirmation, that gets annoying.
> 3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure
> exactly how (haven't investigated fully).
>
> I think the ideal situation is to:
> 1. sandbox filesystem reads to the project folder only
> 2. sandbox filesystem writes to the project folder only
> 3. prevent the plugin from executing scripts that either exist or are have
> been created in the project folder
>
> Not sure how to do this yet though (how to override the node filesystem
> core api temporarily).
>
>
>
>
> On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> yes! (ideally we kill magic folders and make this explicit in the config)
>>
>>
>> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) <
>> v-segreb@microsoft.com> wrote:
>>
>> > Sound like most of us prefer module.export. Cool, will update the code
>> > today and let you know once this is done.
>> >
>> > Since we will be moving to cordova-lib the next action item here could
>> be
>> > creating uniform hooks with shared code for both application level and
>> > plugin level hooks. Thoughts?
>> >
>> > Thx!
>> > Sergey
>> > -----Original Message-----
>> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
>> Of
>> > Brian LeRoux
>> > Sent: Friday, April 18, 2014 8:25 AM
>> > To: dev@cordova.apache.org
>> > Subject: Re: Proposal: hooks support for plugins
>> >
>> > like this too / would be much cleaner
>> >
>> >
>> >
>> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > I like Parashuram's idea. This way the plugin hooks can be testable as
>> > > well?
>> > >
>> > >
>> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH)
>> > > < panarasi@microsoft.com> wrote:
>> > >
>> > > > Currently, the plugin hooks are constructed like the hooks in a
>> > > > cordova project. An alternative would be to construct the javascript
>> > > > files to
>> > > have
>> > > > module.exports, and we could pass in the parameters to the function
>> > > > that
>> > > is
>> > > > exported. This way, the module will not spawn a new node process.
>> > > > Comments, Thoughts?
>> > > >
>> > > > -----Original Message-----
>> > > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
>> > > > Sent: Thursday, April 17, 2014 5:19 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > I've sent a pull request with initial implementation for review.
>> > > > https://github.com/apache/cordova-plugman/pull/74
>> > > >
>> > > > Thx!
>> > > > Sergey
>> > > > -----Original Message-----
>> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
>> > > > Sent: Thursday, March 6, 2014 2:07 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
>> > > > > Can we think about scripts as just a new plugin module? - Similar
>> > > > > to js-module or config-file and which must be processed special
>> > > > > way (by execution).
>> > > > >
>> > > > > <script-module src="src/compile_sqlite.js"/> <framework
>> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
>> > > > > <script-module src="src/add_win8_toastCapable.js"/>
>> > > > > <script-module src="src/set_default_target_paltform_arm.js"/>
>> > > > >
>> > > > > Not so powerful and cool, but easy to implement and understand.
>> > > > > During uninstall each script is called again but with 'uninstall'
>> > > > > flag (or each script file can emit install and uninstall
>> > > > > functions)
>> > > > >
>> > > >
>> > > > I'm all for simple, what happens if one of those scripts fails? E.g.
>> > > > failed compile
>> > > >
>> > > > For example in cli:
>> > > >
>> > > > cordova plugin add sqlite
>> > > > platforms = ['android', 'windows8']; for(p in platforms)
>> > > > installPlugin('sqlite'); // android ok! windows8 fails at
>> > > > 'src/compile_sqlite.js'
>> > > >
>> > > > Is 'sqlite' at that point installed on android? Do we rollback the
>> > > > install? Run the uninstall() scripts?
>> > > >
>> > > > For that reason, sandbox idea seems less chaotic with some hookApi -
>> > > which
>> > > > would cleanup properly if something goes wrong...
>> > > >
>> > > > What you're suggesting seems like it could work, until something
>> > > > goes wrong and leaves the platform(s) project/native in an
>> > inconsistent state.
>> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
>> > > >
>> > > > Could be doable but not sure well it would work.
>> > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Proposal: hooks support for plugins
Posted by Shazron <sh...@gmail.com>.
some ideas here:
https://groups.google.com/forum/#!topic/nodejs/Oq0DEed9kWc
On Fri, Apr 18, 2014 at 11:00 AM, Shazron <sh...@gmail.com> wrote:
> Just food for thought for the future, regarding trust for these scripts,
> based on the discussion so far:
>
> 1. Security model is basically what npm's security model for scripts are
> (full trust)
> 2. We could manually "verify" the scripts (for each update! gets tedious),
> but before it is verified, there is a banner in the plugin registry. Not
> sure how this works with command line adding of plugins with scripts, and
> dependencies, since users will not see that banner, and if we have a text
> warning with confirmation, that gets annoying.
> 3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure
> exactly how (haven't investigated fully).
>
> I think the ideal situation is to:
> 1. sandbox filesystem reads to the project folder only
> 2. sandbox filesystem writes to the project folder only
> 3. prevent the plugin from executing scripts that either exist or are have
> been created in the project folder
>
> Not sure how to do this yet though (how to override the node filesystem
> core api temporarily).
>
>
>
>
> On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> yes! (ideally we kill magic folders and make this explicit in the config)
>>
>>
>> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) <
>> v-segreb@microsoft.com> wrote:
>>
>> > Sound like most of us prefer module.export. Cool, will update the code
>> > today and let you know once this is done.
>> >
>> > Since we will be moving to cordova-lib the next action item here could
>> be
>> > creating uniform hooks with shared code for both application level and
>> > plugin level hooks. Thoughts?
>> >
>> > Thx!
>> > Sergey
>> > -----Original Message-----
>> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
>> Of
>> > Brian LeRoux
>> > Sent: Friday, April 18, 2014 8:25 AM
>> > To: dev@cordova.apache.org
>> > Subject: Re: Proposal: hooks support for plugins
>> >
>> > like this too / would be much cleaner
>> >
>> >
>> >
>> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
>> >
>> > > I like Parashuram's idea. This way the plugin hooks can be testable as
>> > > well?
>> > >
>> > >
>> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH)
>> > > < panarasi@microsoft.com> wrote:
>> > >
>> > > > Currently, the plugin hooks are constructed like the hooks in a
>> > > > cordova project. An alternative would be to construct the javascript
>> > > > files to
>> > > have
>> > > > module.exports, and we could pass in the parameters to the function
>> > > > that
>> > > is
>> > > > exported. This way, the module will not spawn a new node process.
>> > > > Comments, Thoughts?
>> > > >
>> > > > -----Original Message-----
>> > > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
>> > > > Sent: Thursday, April 17, 2014 5:19 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > I've sent a pull request with initial implementation for review.
>> > > > https://github.com/apache/cordova-plugman/pull/74
>> > > >
>> > > > Thx!
>> > > > Sergey
>> > > > -----Original Message-----
>> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
>> > > > Sent: Thursday, March 6, 2014 2:07 PM
>> > > > To: dev@cordova.apache.org
>> > > > Subject: RE: Proposal: hooks support for plugins
>> > > >
>> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
>> > > > > Can we think about scripts as just a new plugin module? - Similar
>> > > > > to js-module or config-file and which must be processed special
>> > > > > way (by execution).
>> > > > >
>> > > > > <script-module src="src/compile_sqlite.js"/> <framework
>> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
>> > > > > <script-module src="src/add_win8_toastCapable.js"/>
>> > > > > <script-module src="src/set_default_target_paltform_arm.js"/>
>> > > > >
>> > > > > Not so powerful and cool, but easy to implement and understand.
>> > > > > During uninstall each script is called again but with 'uninstall'
>> > > > > flag (or each script file can emit install and uninstall
>> > > > > functions)
>> > > > >
>> > > >
>> > > > I'm all for simple, what happens if one of those scripts fails? E.g.
>> > > > failed compile
>> > > >
>> > > > For example in cli:
>> > > >
>> > > > cordova plugin add sqlite
>> > > > platforms = ['android', 'windows8']; for(p in platforms)
>> > > > installPlugin('sqlite'); // android ok! windows8 fails at
>> > > > 'src/compile_sqlite.js'
>> > > >
>> > > > Is 'sqlite' at that point installed on android? Do we rollback the
>> > > > install? Run the uninstall() scripts?
>> > > >
>> > > > For that reason, sandbox idea seems less chaotic with some hookApi -
>> > > which
>> > > > would cleanup properly if something goes wrong...
>> > > >
>> > > > What you're suggesting seems like it could work, until something
>> > > > goes wrong and leaves the platform(s) project/native in an
>> > inconsistent state.
>> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
>> > > >
>> > > > Could be doable but not sure well it would work.
>> > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Proposal: hooks support for plugins
Posted by Shazron <sh...@gmail.com>.
Just food for thought for the future, regarding trust for these scripts,
based on the discussion so far:
1. Security model is basically what npm's security model for scripts are
(full trust)
2. We could manually "verify" the scripts (for each update! gets tedious),
but before it is verified, there is a banner in the plugin registry. Not
sure how this works with command line adding of plugins with scripts, and
dependencies, since users will not see that banner, and if we have a text
warning with confirmation, that gets annoying.
3. Sandboxing possible with http://nodejs.org/api/vm.html ? Not sure
exactly how (haven't investigated fully).
I think the ideal situation is to:
1. sandbox filesystem reads to the project folder only
2. sandbox filesystem writes to the project folder only
3. prevent the plugin from executing scripts that either exist or are have
been created in the project folder
Not sure how to do this yet though (how to override the node filesystem
core api temporarily).
On Fri, Apr 18, 2014 at 8:43 AM, Brian LeRoux <b...@brian.io> wrote:
> yes! (ideally we kill magic folders and make this explicit in the config)
>
>
> On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) <
> v-segreb@microsoft.com> wrote:
>
> > Sound like most of us prefer module.export. Cool, will update the code
> > today and let you know once this is done.
> >
> > Since we will be moving to cordova-lib the next action item here could be
> > creating uniform hooks with shared code for both application level and
> > plugin level hooks. Thoughts?
> >
> > Thx!
> > Sergey
> > -----Original Message-----
> > From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf
> Of
> > Brian LeRoux
> > Sent: Friday, April 18, 2014 8:25 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Proposal: hooks support for plugins
> >
> > like this too / would be much cleaner
> >
> >
> >
> > On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
> >
> > > I like Parashuram's idea. This way the plugin hooks can be testable as
> > > well?
> > >
> > >
> > > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH)
> > > < panarasi@microsoft.com> wrote:
> > >
> > > > Currently, the plugin hooks are constructed like the hooks in a
> > > > cordova project. An alternative would be to construct the javascript
> > > > files to
> > > have
> > > > module.exports, and we could pass in the parameters to the function
> > > > that
> > > is
> > > > exported. This way, the module will not spawn a new node process.
> > > > Comments, Thoughts?
> > > >
> > > > -----Original Message-----
> > > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> > > > Sent: Thursday, April 17, 2014 5:19 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: Proposal: hooks support for plugins
> > > >
> > > > I've sent a pull request with initial implementation for review.
> > > > https://github.com/apache/cordova-plugman/pull/74
> > > >
> > > > Thx!
> > > > Sergey
> > > > -----Original Message-----
> > > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > > > Sent: Thursday, March 6, 2014 2:07 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: Proposal: hooks support for plugins
> > > >
> > > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> > > > > Can we think about scripts as just a new plugin module? - Similar
> > > > > to js-module or config-file and which must be processed special
> > > > > way (by execution).
> > > > >
> > > > > <script-module src="src/compile_sqlite.js"/> <framework
> > > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
> > > > > <script-module src="src/add_win8_toastCapable.js"/>
> > > > > <script-module src="src/set_default_target_paltform_arm.js"/>
> > > > >
> > > > > Not so powerful and cool, but easy to implement and understand.
> > > > > During uninstall each script is called again but with 'uninstall'
> > > > > flag (or each script file can emit install and uninstall
> > > > > functions)
> > > > >
> > > >
> > > > I'm all for simple, what happens if one of those scripts fails? E.g.
> > > > failed compile
> > > >
> > > > For example in cli:
> > > >
> > > > cordova plugin add sqlite
> > > > platforms = ['android', 'windows8']; for(p in platforms)
> > > > installPlugin('sqlite'); // android ok! windows8 fails at
> > > > 'src/compile_sqlite.js'
> > > >
> > > > Is 'sqlite' at that point installed on android? Do we rollback the
> > > > install? Run the uninstall() scripts?
> > > >
> > > > For that reason, sandbox idea seems less chaotic with some hookApi -
> > > which
> > > > would cleanup properly if something goes wrong...
> > > >
> > > > What you're suggesting seems like it could work, until something
> > > > goes wrong and leaves the platform(s) project/native in an
> > inconsistent state.
> > > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
> > > >
> > > > Could be doable but not sure well it would work.
> > > >
> > > >
> > >
> >
>
Re: Proposal: hooks support for plugins
Posted by Brian LeRoux <b...@brian.io>.
yes! (ideally we kill magic folders and make this explicit in the config)
On Fri, Apr 18, 2014 at 8:35 AM, Sergey Grebnov (Akvelon) <
v-segreb@microsoft.com> wrote:
> Sound like most of us prefer module.export. Cool, will update the code
> today and let you know once this is done.
>
> Since we will be moving to cordova-lib the next action item here could be
> creating uniform hooks with shared code for both application level and
> plugin level hooks. Thoughts?
>
> Thx!
> Sergey
> -----Original Message-----
> From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of
> Brian LeRoux
> Sent: Friday, April 18, 2014 8:25 AM
> To: dev@cordova.apache.org
> Subject: Re: Proposal: hooks support for plugins
>
> like this too / would be much cleaner
>
>
>
> On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
>
> > I like Parashuram's idea. This way the plugin hooks can be testable as
> > well?
> >
> >
> > On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH)
> > < panarasi@microsoft.com> wrote:
> >
> > > Currently, the plugin hooks are constructed like the hooks in a
> > > cordova project. An alternative would be to construct the javascript
> > > files to
> > have
> > > module.exports, and we could pass in the parameters to the function
> > > that
> > is
> > > exported. This way, the module will not spawn a new node process.
> > > Comments, Thoughts?
> > >
> > > -----Original Message-----
> > > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> > > Sent: Thursday, April 17, 2014 5:19 PM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Proposal: hooks support for plugins
> > >
> > > I've sent a pull request with initial implementation for review.
> > > https://github.com/apache/cordova-plugman/pull/74
> > >
> > > Thx!
> > > Sergey
> > > -----Original Message-----
> > > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > > Sent: Thursday, March 6, 2014 2:07 PM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Proposal: hooks support for plugins
> > >
> > > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> > > > Can we think about scripts as just a new plugin module? - Similar
> > > > to js-module or config-file and which must be processed special
> > > > way (by execution).
> > > >
> > > > <script-module src="src/compile_sqlite.js"/> <framework
> > > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
> > > > <script-module src="src/add_win8_toastCapable.js"/>
> > > > <script-module src="src/set_default_target_paltform_arm.js"/>
> > > >
> > > > Not so powerful and cool, but easy to implement and understand.
> > > > During uninstall each script is called again but with 'uninstall'
> > > > flag (or each script file can emit install and uninstall
> > > > functions)
> > > >
> > >
> > > I'm all for simple, what happens if one of those scripts fails? E.g.
> > > failed compile
> > >
> > > For example in cli:
> > >
> > > cordova plugin add sqlite
> > > platforms = ['android', 'windows8']; for(p in platforms)
> > > installPlugin('sqlite'); // android ok! windows8 fails at
> > > 'src/compile_sqlite.js'
> > >
> > > Is 'sqlite' at that point installed on android? Do we rollback the
> > > install? Run the uninstall() scripts?
> > >
> > > For that reason, sandbox idea seems less chaotic with some hookApi -
> > which
> > > would cleanup properly if something goes wrong...
> > >
> > > What you're suggesting seems like it could work, until something
> > > goes wrong and leaves the platform(s) project/native in an
> inconsistent state.
> > > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
> > >
> > > Could be doable but not sure well it would work.
> > >
> > >
> >
>
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
Sound like most of us prefer module.export. Cool, will update the code today and let you know once this is done.
Since we will be moving to cordova-lib the next action item here could be creating uniform hooks with shared code for both application level and plugin level hooks. Thoughts?
Thx!
Sergey
-----Original Message-----
From: brian.leroux@gmail.com [mailto:brian.leroux@gmail.com] On Behalf Of Brian LeRoux
Sent: Friday, April 18, 2014 8:25 AM
To: dev@cordova.apache.org
Subject: Re: Proposal: hooks support for plugins
like this too / would be much cleaner
On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
> I like Parashuram's idea. This way the plugin hooks can be testable as
> well?
>
>
> On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH)
> < panarasi@microsoft.com> wrote:
>
> > Currently, the plugin hooks are constructed like the hooks in a
> > cordova project. An alternative would be to construct the javascript
> > files to
> have
> > module.exports, and we could pass in the parameters to the function
> > that
> is
> > exported. This way, the module will not spawn a new node process.
> > Comments, Thoughts?
> >
> > -----Original Message-----
> > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> > Sent: Thursday, April 17, 2014 5:19 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: hooks support for plugins
> >
> > I've sent a pull request with initial implementation for review.
> > https://github.com/apache/cordova-plugman/pull/74
> >
> > Thx!
> > Sergey
> > -----Original Message-----
> > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > Sent: Thursday, March 6, 2014 2:07 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: hooks support for plugins
> >
> > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> > > Can we think about scripts as just a new plugin module? - Similar
> > > to js-module or config-file and which must be processed special
> > > way (by execution).
> > >
> > > <script-module src="src/compile_sqlite.js"/> <framework
> > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
> > > <script-module src="src/add_win8_toastCapable.js"/>
> > > <script-module src="src/set_default_target_paltform_arm.js"/>
> > >
> > > Not so powerful and cool, but easy to implement and understand.
> > > During uninstall each script is called again but with 'uninstall'
> > > flag (or each script file can emit install and uninstall
> > > functions)
> > >
> >
> > I'm all for simple, what happens if one of those scripts fails? E.g.
> > failed compile
> >
> > For example in cli:
> >
> > cordova plugin add sqlite
> > platforms = ['android', 'windows8']; for(p in platforms)
> > installPlugin('sqlite'); // android ok! windows8 fails at
> > 'src/compile_sqlite.js'
> >
> > Is 'sqlite' at that point installed on android? Do we rollback the
> > install? Run the uninstall() scripts?
> >
> > For that reason, sandbox idea seems less chaotic with some hookApi -
> which
> > would cleanup properly if something goes wrong...
> >
> > What you're suggesting seems like it could work, until something
> > goes wrong and leaves the platform(s) project/native in an inconsistent state.
> > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
> >
> > Could be doable but not sure well it would work.
> >
> >
>
Re: Proposal: hooks support for plugins
Posted by Brian LeRoux <b...@brian.io>.
like this too / would be much cleaner
On Thu, Apr 17, 2014 at 5:38 PM, Shazron <sh...@gmail.com> wrote:
> I like Parashuram's idea. This way the plugin hooks can be testable as
> well?
>
>
> On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH) <
> panarasi@microsoft.com> wrote:
>
> > Currently, the plugin hooks are constructed like the hooks in a cordova
> > project. An alternative would be to construct the javascript files to
> have
> > module.exports, and we could pass in the parameters to the function that
> is
> > exported. This way, the module will not spawn a new node process.
> > Comments, Thoughts?
> >
> > -----Original Message-----
> > From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> > Sent: Thursday, April 17, 2014 5:19 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: hooks support for plugins
> >
> > I've sent a pull request with initial implementation for review.
> > https://github.com/apache/cordova-plugman/pull/74
> >
> > Thx!
> > Sergey
> > -----Original Message-----
> > From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> > Sent: Thursday, March 6, 2014 2:07 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Proposal: hooks support for plugins
> >
> > On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> > > Can we think about scripts as just a new plugin module? - Similar to
> > > js-module or config-file and which must be processed special way (by
> > > execution).
> > >
> > > <script-module src="src/compile_sqlite.js"/> <framework
> > > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> <script-module
> > > src="src/add_win8_toastCapable.js"/>
> > > <script-module src="src/set_default_target_paltform_arm.js"/>
> > >
> > > Not so powerful and cool, but easy to implement and understand. During
> > > uninstall each script is called again but with 'uninstall' flag (or
> > > each script file can emit install and uninstall functions)
> > >
> >
> > I'm all for simple, what happens if one of those scripts fails? E.g.
> > failed compile
> >
> > For example in cli:
> >
> > cordova plugin add sqlite
> > platforms = ['android', 'windows8'];
> > for(p in platforms)
> > installPlugin('sqlite'); // android ok! windows8 fails at
> > 'src/compile_sqlite.js'
> >
> > Is 'sqlite' at that point installed on android? Do we rollback the
> > install? Run the uninstall() scripts?
> >
> > For that reason, sandbox idea seems less chaotic with some hookApi -
> which
> > would cleanup properly if something goes wrong...
> >
> > What you're suggesting seems like it could work, until something goes
> > wrong and leaves the platform(s) project/native in an inconsistent state.
> > Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
> >
> > Could be doable but not sure well it would work.
> >
> >
>
Re: Proposal: hooks support for plugins
Posted by Shazron <sh...@gmail.com>.
I like Parashuram's idea. This way the plugin hooks can be testable as well?
On Thu, Apr 17, 2014 at 5:22 PM, Parashuram Narasimhan (MS OPEN TECH) <
panarasi@microsoft.com> wrote:
> Currently, the plugin hooks are constructed like the hooks in a cordova
> project. An alternative would be to construct the javascript files to have
> module.exports, and we could pass in the parameters to the function that is
> exported. This way, the module will not spawn a new node process.
> Comments, Thoughts?
>
> -----Original Message-----
> From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
> Sent: Thursday, April 17, 2014 5:19 PM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: hooks support for plugins
>
> I've sent a pull request with initial implementation for review.
> https://github.com/apache/cordova-plugman/pull/74
>
> Thx!
> Sergey
> -----Original Message-----
> From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
> Sent: Thursday, March 6, 2014 2:07 PM
> To: dev@cordova.apache.org
> Subject: RE: Proposal: hooks support for plugins
>
> On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> > Can we think about scripts as just a new plugin module? - Similar to
> > js-module or config-file and which must be processed special way (by
> > execution).
> >
> > <script-module src="src/compile_sqlite.js"/> <framework
> > src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> <script-module
> > src="src/add_win8_toastCapable.js"/>
> > <script-module src="src/set_default_target_paltform_arm.js"/>
> >
> > Not so powerful and cool, but easy to implement and understand. During
> > uninstall each script is called again but with 'uninstall' flag (or
> > each script file can emit install and uninstall functions)
> >
>
> I'm all for simple, what happens if one of those scripts fails? E.g.
> failed compile
>
> For example in cli:
>
> cordova plugin add sqlite
> platforms = ['android', 'windows8'];
> for(p in platforms)
> installPlugin('sqlite'); // android ok! windows8 fails at
> 'src/compile_sqlite.js'
>
> Is 'sqlite' at that point installed on android? Do we rollback the
> install? Run the uninstall() scripts?
>
> For that reason, sandbox idea seems less chaotic with some hookApi - which
> would cleanup properly if something goes wrong...
>
> What you're suggesting seems like it could work, until something goes
> wrong and leaves the platform(s) project/native in an inconsistent state.
> Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
>
> Could be doable but not sure well it would work.
>
>
RE: Proposal: hooks support for plugins
Posted by "Parashuram Narasimhan (MS OPEN TECH)" <pa...@microsoft.com>.
Currently, the plugin hooks are constructed like the hooks in a cordova project. An alternative would be to construct the javascript files to have module.exports, and we could pass in the parameters to the function that is exported. This way, the module will not spawn a new node process.
Comments, Thoughts?
-----Original Message-----
From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
Sent: Thursday, April 17, 2014 5:19 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
I've sent a pull request with initial implementation for review.
https://github.com/apache/cordova-plugman/pull/74
Thx!
Sergey
-----Original Message-----
From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
Sent: Thursday, March 6, 2014 2:07 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> Can we think about scripts as just a new plugin module? - Similar to
> js-module or config-file and which must be processed special way (by
> execution).
>
> <script-module src="src/compile_sqlite.js"/> <framework
> src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> <script-module
> src="src/add_win8_toastCapable.js"/>
> <script-module src="src/set_default_target_paltform_arm.js"/>
>
> Not so powerful and cool, but easy to implement and understand. During
> uninstall each script is called again but with 'uninstall' flag (or
> each script file can emit install and uninstall functions)
>
I'm all for simple, what happens if one of those scripts fails? E.g. failed compile
For example in cli:
cordova plugin add sqlite
platforms = ['android', 'windows8'];
for(p in platforms)
installPlugin('sqlite'); // android ok! windows8 fails at 'src/compile_sqlite.js'
Is 'sqlite' at that point installed on android? Do we rollback the install? Run the uninstall() scripts?
For that reason, sandbox idea seems less chaotic with some hookApi - which would cleanup properly if something goes wrong...
What you're suggesting seems like it could work, until something goes wrong and leaves the platform(s) project/native in an inconsistent state. Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
Could be doable but not sure well it would work.
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
I've sent a pull request with initial implementation for review.
https://github.com/apache/cordova-plugman/pull/74
Thx!
Sergey
-----Original Message-----
From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
Sent: Thursday, March 6, 2014 2:07 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> Can we think about scripts as just a new plugin module? - Similar to
> js-module or config-file and which must be processed special way (by
> execution).
>
> <script-module src="src/compile_sqlite.js"/> <framework
> src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> <script-module
> src="src/add_win8_toastCapable.js"/>
> <script-module src="src/set_default_target_paltform_arm.js"/>
>
> Not so powerful and cool, but easy to implement and understand. During
> uninstall each script is called again but with 'uninstall' flag (or
> each script file can emit install and uninstall functions)
>
I'm all for simple, what happens if one of those scripts fails? E.g. failed compile
For example in cli:
cordova plugin add sqlite
platforms = ['android', 'windows8'];
for(p in platforms)
installPlugin('sqlite'); // android ok! windows8 fails at 'src/compile_sqlite.js'
Is 'sqlite' at that point installed on android? Do we rollback the install? Run the uninstall() scripts?
For that reason, sandbox idea seems less chaotic with some hookApi - which would cleanup properly if something goes wrong...
What you're suggesting seems like it could work, until something goes wrong and leaves the platform(s) project/native in an inconsistent state. Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
Could be doable but not sure well it would work.
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Thu Mar 6 01:57 PM, Sergey Grebnov (Akvelon) wrote:
> Can we think about scripts as just a new plugin module? - Similar to
> js-module or
> config-file and which must be processed special way (by
> execution).
>
> <script-module src="src/compile_sqlite.js"/> <framework
> src="src/windows8/SQLitePCL.Ext.dll" custom="true"/> <script-module
> src="src/add_win8_toastCapable.js"/>
> <script-module src="src/set_default_target_paltform_arm.js"/>
>
> Not so powerful and cool, but easy to implement and understand. During
> uninstall each script is called again but with 'uninstall' flag (or each
> script file can
> emit install and uninstall functions)
>
I'm all for simple, what happens if one of those scripts fails? E.g. failed compile
For example in cli:
cordova plugin add sqlite
platforms = ['android', 'windows8'];
for(p in platforms)
installPlugin('sqlite'); // android ok! windows8 fails at 'src/compile_sqlite.js'
Is 'sqlite' at that point installed on android? Do we rollback the install? Run the uninstall() scripts?
For that reason, sandbox idea seems less chaotic with some hookApi - which would cleanup properly if something goes wrong...
What you're suggesting seems like it could work, until something goes wrong and leaves the platform(s) project/native in an inconsistent state. Multiple that with "pluginb" that fails at 'src/compile_stuff.js'
Could be doable but not sure well it would work.
RE: Proposal: hooks support for plugins
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
Can we think about scripts as just a new plugin module? - Similar to js-module or config-file and which must be processed special way (by execution).
<script-module src="src/compile_sqlite.js"/>
<framework src="src/windows8/SQLitePCL.Ext.dll" custom="true"/>
<script-module src="src/add_win8_toastCapable.js"/>
<script-module src="src/set_default_target_paltform_arm.js"/>
Not so powerful and cool, but easy to implement and understand. During uninstall each script is called again but with 'uninstall' flag (or each script file can emit install and uninstall functions)
Thx!
Sergey
-----Original Message-----
From: Jonathan Bond-Caron [mailto:jbondc@gdesolutions.com]
Sent: Thursday, March 6, 2014 9:31 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: hooks support for plugins
On Thu Mar 6 11:41 AM, Michal Mocny wrote:
> On Thu, Mar 6, 2014 at 11:16 AM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> > > For cli workflow: hooks (including plugin hooks) can access
> > > config.xml <preference>'s for things like the sqllite compile
> > > example (recompile
> > only if
> > > settings changed would be nice), and access <preference> at
> > > runtime for
> > the
> > > console example.
> > >
> > > For old workflow, perhaps sqllite is documented to manually run
> > > the hook
> > to
> > > recompile whenever you want to change the default setting?
> > >
> > > Just thinking about alternatives and/or solutions that are
> > > actually
> > feasible short
> > > term.
> > >
> >
> > Ya it could work, maybe something like:
> > <preference name="cordova-plugin-console@install"
> > value="--prefer-console true" /> (passed to an install script)
> >
>
> Thats not what I am suggesting. I am suggesting:
>
> <preference name="cordova-plugin-console-some-setting" value="true"
> />
>
So...
<preference name="cordova-plugin-console/install/some-setting" value="true" /> <preference name="cordova-plugin-console/blah/some-setting" value="true" /> <preference name="android/cordova-plugin-console/blah/some-setting" value="false" />
Looks like a windows registry to me, build a tree from it.
Heck, everything is just a preference (sarcasm):
<preference name="android/icon/[56x56]" value="some/path.png" /> <preference name="android/app/name" value="broken app" />
Ultimately 'preference' tag always wins.
Joke aside, the part that's special about the plugin hooks is a need to track installed files for uninstall() & the security issue (sandbox or not).
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Thu Mar 6 11:41 AM, Michal Mocny wrote:
> On Thu, Mar 6, 2014 at 11:16 AM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> > > For cli workflow: hooks (including plugin hooks) can access
> > > config.xml <preference>'s for things like the sqllite compile
> > > example (recompile
> > only if
> > > settings changed would be nice), and access <preference> at runtime
> > > for
> > the
> > > console example.
> > >
> > > For old workflow, perhaps sqllite is documented to manually run the
> > > hook
> > to
> > > recompile whenever you want to change the default setting?
> > >
> > > Just thinking about alternatives and/or solutions that are actually
> > feasible short
> > > term.
> > >
> >
> > Ya it could work, maybe something like:
> > <preference name="cordova-plugin-console@install"
> > value="--prefer-console true" /> (passed to an install script)
> >
>
> Thats not what I am suggesting. I am suggesting:
>
> <preference name="cordova-plugin-console-some-setting" value="true" />
>
So...
<preference name="cordova-plugin-console/install/some-setting" value="true" />
<preference name="cordova-plugin-console/blah/some-setting" value="true" />
<preference name="android/cordova-plugin-console/blah/some-setting" value="false" />
Looks like a windows registry to me, build a tree from it.
Heck, everything is just a preference (sarcasm):
<preference name="android/icon/[56x56]" value="some/path.png" />
<preference name="android/app/name" value="broken app" />
Ultimately 'preference' tag always wins.
Joke aside, the part that's special about the plugin hooks is a need to track installed files for uninstall() & the security issue (sandbox or not).
Re: Proposal: hooks support for plugins
Posted by Michal Mocny <mm...@chromium.org>.
On Thu, Mar 6, 2014 at 11:16 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> > For cli workflow: hooks (including plugin hooks) can access config.xml
> > <preference>'s for things like the sqllite compile example (recompile
> only if
> > settings changed would be nice), and access <preference> at runtime for
> the
> > console example.
> >
> > For old workflow, perhaps sqllite is documented to manually run the hook
> to
> > recompile whenever you want to change the default setting?
> >
> > Just thinking about alternatives and/or solutions that are actually
> feasible short
> > term.
> >
>
> Ya it could work, maybe something like:
> <preference name="cordova-plugin-console@install" value="--prefer-console
> true" /> (passed to an install script)
>
Thats not what I am suggesting. I am suggesting:
<preference name="cordova-plugin-console-some-setting" value="true" />
CLI and Plugman remain oblivious.
Inside hooks, you use regular file access to open config.xml, parse it, and
use that value. We could provide a node lib to assist with this (finding
the location of config.xml and parsing the file are tasks that we wouldn't
want to have to re-invent).
The point merely being, you can configure what hooks do without changing
our tools. I think we should prefer to make plugman do as little as
possible (lest it turn into coho ;).
> Keep in mind 'install' options/config (only used once during the install
> process) aren't the same as 'runtime' options/config (dynamic, changed by
> user)
>
> <preference name="cordova-plugin-console:use-console" value="true" />
> (runtime options?)
> <preference name="cordova-plugin-console:color" value="pink" />
>
> Some high level code at how the install script could work:
>
> https://github.com/jbondc/cordova-labs/blob/master/cordova-plugin-echo/plugin.xml#L14
>
> https://github.com/jbondc/cordova-labs/blob/master/cordova-plugin-echo/src/preinstall.js
>
> Not sure if we need a 'postinstall' script, instead in the preinstall.js
> could do something like:
> project.onPostInstall('plugin.name', function(hookApi){
>
> // do something else..
>
> });
>
> Many ways it could work, this is more pursuing the sandbox idea.
>
>
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Wed Mar 5 04:13 PM, Michal Mocny wrote:
> For cli workflow: hooks (including plugin hooks) can access config.xml
> <preference>'s for things like the sqllite compile example (recompile only if
> settings changed would be nice), and access <preference> at runtime for the
> console example.
>
> For old workflow, perhaps sqllite is documented to manually run the hook to
> recompile whenever you want to change the default setting?
>
> Just thinking about alternatives and/or solutions that are actually feasible short
> term.
>
Ya it could work, maybe something like:
<preference name="cordova-plugin-console@install" value="--prefer-console true" /> (passed to an install script)
Keep in mind 'install' options/config (only used once during the install process) aren't the same as 'runtime' options/config (dynamic, changed by user)
<preference name="cordova-plugin-console:use-console" value="true" /> (runtime options?)
<preference name="cordova-plugin-console:color" value="pink" />
Some high level code at how the install script could work:
https://github.com/jbondc/cordova-labs/blob/master/cordova-plugin-echo/plugin.xml#L14
https://github.com/jbondc/cordova-labs/blob/master/cordova-plugin-echo/src/preinstall.js
Not sure if we need a 'postinstall' script, instead in the preinstall.js could do something like:
project.onPostInstall('plugin.name', function(hookApi){
// do something else..
});
Many ways it could work, this is more pursuing the sandbox idea.
Re: Proposal: hooks support for plugins
Posted by Michal Mocny <mm...@chromium.org>.
For cli workflow: hooks (including plugin hooks) can access config.xml
<preference>'s for things like the sqllite compile example (recompile only
if settings changed would be nice), and access <preference> at runtime for
the console example.
For old workflow, perhaps sqllite is documented to manually run the hook to
recompile whenever you want to change the default setting?
Just thinking about alternatives and/or solutions that are actually
feasible short term.
-Michal
On Wed, Mar 5, 2014 at 4:03 PM, Jesse <pu...@gmail.com> wrote:
> Okay, you convinced me. args make sense for hooks for preinstall/install
> hooks, everything else, the plugin scripts should be able to manage on
> their own by writing some config/settings data to it's own plugin folder.
>
> I think the bigger discussion for now needs to be around the permissions,
> security, and policy.
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Mar 5, 2014 at 12:48 PM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Wed Mar 5 02:54 PM, Jesse wrote:
> > > I am a no to passing arguments, the use-case is really about doing some
> > > extra
> > > tasks for the current environment.
> > >
> >
> > Not necessarily:
> >
> >
> https://github.com/apache/cordova-plugin-console/blob/master/www/logger.js#L48
> >
> > cordova plugin add cordova-plugin-console --use-console true (preinstall
> > script tries to keep console.log on platforms where it exists)
> >
> > It's also about options to support different workflows.
> >
> > For sqlite (which would be awesome btw), it's also enabling/disabling
> > default compile options:
> > https://sqlite.org/compile.html
> >
> > I'm not saying this can be done short term or that the extra complexity
> is
> > worth it but should consider looking into it...
> >
> >
>
Re: Proposal: hooks support for plugins
Posted by Jesse <pu...@gmail.com>.
Okay, you convinced me. args make sense for hooks for preinstall/install
hooks, everything else, the plugin scripts should be able to manage on
their own by writing some config/settings data to it's own plugin folder.
I think the bigger discussion for now needs to be around the permissions,
security, and policy.
@purplecabbage
risingj.com
On Wed, Mar 5, 2014 at 12:48 PM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Wed Mar 5 02:54 PM, Jesse wrote:
> > I am a no to passing arguments, the use-case is really about doing some
> > extra
> > tasks for the current environment.
> >
>
> Not necessarily:
>
> https://github.com/apache/cordova-plugin-console/blob/master/www/logger.js#L48
>
> cordova plugin add cordova-plugin-console --use-console true (preinstall
> script tries to keep console.log on platforms where it exists)
>
> It's also about options to support different workflows.
>
> For sqlite (which would be awesome btw), it's also enabling/disabling
> default compile options:
> https://sqlite.org/compile.html
>
> I'm not saying this can be done short term or that the extra complexity is
> worth it but should consider looking into it...
>
>
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Wed Mar 5 02:54 PM, Jesse wrote:
> I am a no to passing arguments, the use-case is really about doing some
> extra
> tasks for the current environment.
>
Not necessarily:
https://github.com/apache/cordova-plugin-console/blob/master/www/logger.js#L48
cordova plugin add cordova-plugin-console --use-console true (preinstall script tries to keep console.log on platforms where it exists)
It's also about options to support different workflows.
For sqlite (which would be awesome btw), it's also enabling/disabling default compile options:
https://sqlite.org/compile.html
I'm not saying this can be done short term or that the extra complexity is worth it but should consider looking into it...
Re: Proposal: hooks support for plugins
Posted by Jesse <pu...@gmail.com>.
We also have to keep the whole dependency tree in mind as well.
ie. com.plugins.benign depends on com.plugins.nefarious
Not sure how a warning banner would address this.
@purplecabbage
risingj.com
On Wed, Mar 5, 2014 at 12:30 PM, Michal Mocny <mm...@chromium.org> wrote:
> On Wed, Mar 5, 2014 at 3:30 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> >
> >
> >
> > On Wed, Mar 5, 2014 at 3:02 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> Agree w/ your points Jesse. I'm going to reach out to Maven folks to
> find
> >> out what they've done wrt to publishing policy.
> >>
> >>
> >> On Wed, Mar 5, 2014 at 11:54 AM, Jesse <pu...@gmail.com> wrote:
> >>
> >> > I am a no to passing arguments, the use-case is really about doing
> some
> >> > extra tasks for the current environment.
> >> >
> >> > I am also a 'no' to prompting the user for permission, this shortly
> >> becomes
> >> > a permission list of which plugins can and can't run scripts, or do we
> >> ask
> >> > this every time?
> >> >
> >> > We definitely need to post our policies for plugins. ie.something like
> >> > npmjs.org posts [1]
> >> >
> >> > We may want to not allow auto publishing of any plugin that uses these
> >> > scripts, and have one of us look at it quickly to make sure it is not
> >> evil.
> >>
> >
> > Not bad of an idea. I suggest perhaps we do this by adding a banner to
> > plugins.cordova.io: "Warning, not verified yet, may be malicious [click
> > to vouch for this]". This way, plugin publishers can eat their own lunch
> > right away, and plugin publishers don't get frustrated when we inevitably
> > become lazy gatekeepers.
> >
>
> What I mean is: put up the banner until verified, but don't block
> downloads.
>
>
> >
> >
> >> >
> >> >
> >> > [1] https://www.npmjs.org/doc/misc/npm-disputes.html ( the exceptions
> >> > section )
> >> >
> >> >
> >> > @purplecabbage
> >> > risingj.com
> >> >
> >> >
> >> > On Wed, Mar 5, 2014 at 11:21 AM, Andrew Grieve <ag...@chromium.org>
> >> > wrote:
> >> >
> >> > > Not sure passing through command-line arguments is feasible for
> >> dependent
> >> > > plugins. Maybe have the scripts get their args from environment
> >> > variables?
> >> > >
> >> > >
> >> > > On Wed, Mar 5, 2014 at 12:59 PM, Jonathan Bond-Caron <
> >> > > jbondc@gdesolutions.com> wrote:
> >> > >
> >> > > > On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> >> > > > > In that case (i.e., "npm test") the user is explicitly invoking
> >> the
> >> > > > > script. If we are
> >> > > > > talking about hooks that run automatically on
> >> > > > > "cordova plugin add", then it is
> >> > > > > implicit. How about if the cli
> >> > > > > prompted the user when a hook request is present
> >> > > > > such as "plugin
> >> > > > > foobar wants to run the script xyz. Do you grant permission for
> it
> >> > > > > to
> >> > > > > do so?" Perhaps plugman could have an --accept-scripts parm that
> >> > > > > granted
> >> > > > > permission to all such requests to prevent prompting?
> >> > > >
> >> > > > Could run scripts in a 'sandbox' of some sort...
> >> > > > http://nodejs.org/api/vm.html
> >> > > >
> >> > > > Might be a little safer and less chaotic in terms of what scripts
> >> can
> >> > > > install, that way uninstall() can cleanly do its job.
> >> > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: Proposal: hooks support for plugins
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Mar 5, 2014 at 3:30 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>
>
> On Wed, Mar 5, 2014 at 3:02 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> Agree w/ your points Jesse. I'm going to reach out to Maven folks to find
>> out what they've done wrt to publishing policy.
>>
>>
>> On Wed, Mar 5, 2014 at 11:54 AM, Jesse <pu...@gmail.com> wrote:
>>
>> > I am a no to passing arguments, the use-case is really about doing some
>> > extra tasks for the current environment.
>> >
>> > I am also a 'no' to prompting the user for permission, this shortly
>> becomes
>> > a permission list of which plugins can and can't run scripts, or do we
>> ask
>> > this every time?
>> >
>> > We definitely need to post our policies for plugins. ie.something like
>> > npmjs.org posts [1]
>> >
>> > We may want to not allow auto publishing of any plugin that uses these
>> > scripts, and have one of us look at it quickly to make sure it is not
>> evil.
>>
>
> Not bad of an idea. I suggest perhaps we do this by adding a banner to
> plugins.cordova.io: "Warning, not verified yet, may be malicious [click
> to vouch for this]". This way, plugin publishers can eat their own lunch
> right away, and plugin publishers don't get frustrated when we inevitably
> become lazy gatekeepers.
>
What I mean is: put up the banner until verified, but don't block downloads.
>
>
>> >
>> >
>> > [1] https://www.npmjs.org/doc/misc/npm-disputes.html ( the exceptions
>> > section )
>> >
>> >
>> > @purplecabbage
>> > risingj.com
>> >
>> >
>> > On Wed, Mar 5, 2014 at 11:21 AM, Andrew Grieve <ag...@chromium.org>
>> > wrote:
>> >
>> > > Not sure passing through command-line arguments is feasible for
>> dependent
>> > > plugins. Maybe have the scripts get their args from environment
>> > variables?
>> > >
>> > >
>> > > On Wed, Mar 5, 2014 at 12:59 PM, Jonathan Bond-Caron <
>> > > jbondc@gdesolutions.com> wrote:
>> > >
>> > > > On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
>> > > > > In that case (i.e., "npm test") the user is explicitly invoking
>> the
>> > > > > script. If we are
>> > > > > talking about hooks that run automatically on
>> > > > > "cordova plugin add", then it is
>> > > > > implicit. How about if the cli
>> > > > > prompted the user when a hook request is present
>> > > > > such as "plugin
>> > > > > foobar wants to run the script xyz. Do you grant permission for it
>> > > > > to
>> > > > > do so?" Perhaps plugman could have an --accept-scripts parm that
>> > > > > granted
>> > > > > permission to all such requests to prevent prompting?
>> > > >
>> > > > Could run scripts in a 'sandbox' of some sort...
>> > > > http://nodejs.org/api/vm.html
>> > > >
>> > > > Might be a little safer and less chaotic in terms of what scripts
>> can
>> > > > install, that way uninstall() can cleanly do its job.
>> > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Proposal: hooks support for plugins
Posted by Michal Mocny <mm...@chromium.org>.
On Wed, Mar 5, 2014 at 3:02 PM, Brian LeRoux <b...@brian.io> wrote:
> Agree w/ your points Jesse. I'm going to reach out to Maven folks to find
> out what they've done wrt to publishing policy.
>
>
> On Wed, Mar 5, 2014 at 11:54 AM, Jesse <pu...@gmail.com> wrote:
>
> > I am a no to passing arguments, the use-case is really about doing some
> > extra tasks for the current environment.
> >
> > I am also a 'no' to prompting the user for permission, this shortly
> becomes
> > a permission list of which plugins can and can't run scripts, or do we
> ask
> > this every time?
> >
> > We definitely need to post our policies for plugins. ie.something like
> > npmjs.org posts [1]
> >
> > We may want to not allow auto publishing of any plugin that uses these
> > scripts, and have one of us look at it quickly to make sure it is not
> evil.
>
Not bad of an idea. I suggest perhaps we do this by adding a banner to
plugins.cordova.io: "Warning, not verified yet, may be malicious [click to
vouch for this]". This way, plugin publishers can eat their own lunch
right away, and plugin publishers don't get frustrated when we inevitably
become lazy gatekeepers.
> >
> >
> > [1] https://www.npmjs.org/doc/misc/npm-disputes.html ( the exceptions
> > section )
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Mar 5, 2014 at 11:21 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > Not sure passing through command-line arguments is feasible for
> dependent
> > > plugins. Maybe have the scripts get their args from environment
> > variables?
> > >
> > >
> > > On Wed, Mar 5, 2014 at 12:59 PM, Jonathan Bond-Caron <
> > > jbondc@gdesolutions.com> wrote:
> > >
> > > > On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> > > > > In that case (i.e., "npm test") the user is explicitly invoking the
> > > > > script. If we are
> > > > > talking about hooks that run automatically on
> > > > > "cordova plugin add", then it is
> > > > > implicit. How about if the cli
> > > > > prompted the user when a hook request is present
> > > > > such as "plugin
> > > > > foobar wants to run the script xyz. Do you grant permission for it
> > > > > to
> > > > > do so?" Perhaps plugman could have an --accept-scripts parm that
> > > > > granted
> > > > > permission to all such requests to prevent prompting?
> > > >
> > > > Could run scripts in a 'sandbox' of some sort...
> > > > http://nodejs.org/api/vm.html
> > > >
> > > > Might be a little safer and less chaotic in terms of what scripts can
> > > > install, that way uninstall() can cleanly do its job.
> > > >
> > > >
> > >
> >
>
Re: Proposal: hooks support for plugins
Posted by Brian LeRoux <b...@brian.io>.
Agree w/ your points Jesse. I'm going to reach out to Maven folks to find
out what they've done wrt to publishing policy.
On Wed, Mar 5, 2014 at 11:54 AM, Jesse <pu...@gmail.com> wrote:
> I am a no to passing arguments, the use-case is really about doing some
> extra tasks for the current environment.
>
> I am also a 'no' to prompting the user for permission, this shortly becomes
> a permission list of which plugins can and can't run scripts, or do we ask
> this every time?
>
> We definitely need to post our policies for plugins. ie.something like
> npmjs.org posts [1]
>
> We may want to not allow auto publishing of any plugin that uses these
> scripts, and have one of us look at it quickly to make sure it is not evil.
>
>
> [1] https://www.npmjs.org/doc/misc/npm-disputes.html ( the exceptions
> section )
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Mar 5, 2014 at 11:21 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Not sure passing through command-line arguments is feasible for dependent
> > plugins. Maybe have the scripts get their args from environment
> variables?
> >
> >
> > On Wed, Mar 5, 2014 at 12:59 PM, Jonathan Bond-Caron <
> > jbondc@gdesolutions.com> wrote:
> >
> > > On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> > > > In that case (i.e., "npm test") the user is explicitly invoking the
> > > > script. If we are
> > > > talking about hooks that run automatically on
> > > > "cordova plugin add", then it is
> > > > implicit. How about if the cli
> > > > prompted the user when a hook request is present
> > > > such as "plugin
> > > > foobar wants to run the script xyz. Do you grant permission for it
> > > > to
> > > > do so?" Perhaps plugman could have an --accept-scripts parm that
> > > > granted
> > > > permission to all such requests to prevent prompting?
> > >
> > > Could run scripts in a 'sandbox' of some sort...
> > > http://nodejs.org/api/vm.html
> > >
> > > Might be a little safer and less chaotic in terms of what scripts can
> > > install, that way uninstall() can cleanly do its job.
> > >
> > >
> >
>
Re: Proposal: hooks support for plugins
Posted by Jesse <pu...@gmail.com>.
I am a no to passing arguments, the use-case is really about doing some
extra tasks for the current environment.
I am also a 'no' to prompting the user for permission, this shortly becomes
a permission list of which plugins can and can't run scripts, or do we ask
this every time?
We definitely need to post our policies for plugins. ie.something like
npmjs.org posts [1]
We may want to not allow auto publishing of any plugin that uses these
scripts, and have one of us look at it quickly to make sure it is not evil.
[1] https://www.npmjs.org/doc/misc/npm-disputes.html ( the exceptions
section )
@purplecabbage
risingj.com
On Wed, Mar 5, 2014 at 11:21 AM, Andrew Grieve <ag...@chromium.org> wrote:
> Not sure passing through command-line arguments is feasible for dependent
> plugins. Maybe have the scripts get their args from environment variables?
>
>
> On Wed, Mar 5, 2014 at 12:59 PM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> > > In that case (i.e., "npm test") the user is explicitly invoking the
> > > script. If we are
> > > talking about hooks that run automatically on
> > > "cordova plugin add", then it is
> > > implicit. How about if the cli
> > > prompted the user when a hook request is present
> > > such as "plugin
> > > foobar wants to run the script xyz. Do you grant permission for it
> > > to
> > > do so?" Perhaps plugman could have an --accept-scripts parm that
> > > granted
> > > permission to all such requests to prevent prompting?
> >
> > Could run scripts in a 'sandbox' of some sort...
> > http://nodejs.org/api/vm.html
> >
> > Might be a little safer and less chaotic in terms of what scripts can
> > install, that way uninstall() can cleanly do its job.
> >
> >
>
Re: Proposal: hooks support for plugins
Posted by Andrew Grieve <ag...@chromium.org>.
Not sure passing through command-line arguments is feasible for dependent
plugins. Maybe have the scripts get their args from environment variables?
On Wed, Mar 5, 2014 at 12:59 PM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> > In that case (i.e., "npm test") the user is explicitly invoking the
> > script. If we are
> > talking about hooks that run automatically on
> > "cordova plugin add", then it is
> > implicit. How about if the cli
> > prompted the user when a hook request is present
> > such as "plugin
> > foobar wants to run the script xyz. Do you grant permission for it
> > to
> > do so?" Perhaps plugman could have an --accept-scripts parm that
> > granted
> > permission to all such requests to prevent prompting?
>
> Could run scripts in a 'sandbox' of some sort...
> http://nodejs.org/api/vm.html
>
> Might be a little safer and less chaotic in terms of what scripts can
> install, that way uninstall() can cleanly do its job.
>
>
RE: Proposal: hooks support for plugins
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Wed Mar 5 12:00 PM, Marcel Kinard wrote:
> In that case (i.e., "npm test") the user is explicitly invoking the
> script. If we are
> talking about hooks that run automatically on
> "cordova plugin add", then it is
> implicit. How about if the cli
> prompted the user when a hook request is present
> such as "plugin
> foobar wants to run the script xyz. Do you grant permission for it
> to
> do so?" Perhaps plugman could have an --accept-scripts parm that
> granted
> permission to all such requests to prevent prompting?
Could run scripts in a 'sandbox' of some sort...
http://nodejs.org/api/vm.html
Might be a little safer and less chaotic in terms of what scripts can install, that way uninstall() can cleanly do its job.
Re: Proposal: hooks support for plugins
Posted by Marcel Kinard <cm...@gmail.com>.
In that case (i.e., "npm test") the user is explicitly invoking the script. If we are talking about hooks that run automatically on "cordova plugin add", then it is implicit. How about if the cli prompted the user when a hook request is present such as "plugin foobar wants to run the script xyz. Do you grant permission for it to do so?" Perhaps plugman could have an --accept-scripts parm that granted permission to all such requests to prevent prompting?
On Mar 3, 2014, at 2:11 PM, Parashuram Narasimhan (MS OPEN TECH) <pa...@microsoft.com> wrote:
> Note that this is very similar to npm. My guess is that security story would be the same.
RE: Proposal: hooks support for plugins
Posted by "Parashuram Narasimhan (MS OPEN TECH)" <pa...@microsoft.com>.
Note that this is very similar to npm. My guess is that security story would be the same.
-----Original Message-----
From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew Grieve
Sent: Monday, March 3, 2014 10:45 AM
To: dev
Subject: Re: Proposal: hooks support for plugins
There's definitely a security angle to this. E.g. You install a plugin and now it's running code on your machine in a non-sandboxed way. Maybe could warn before running the script for the first time, or show a badge on its plugins.cordova.io page to highlight this.
install hooks might make it harder to uninstall a plugin as well.
On Sat, Mar 1, 2014 at 6:47 PM, Jesse <pu...@gmail.com> wrote:
> I originally replied to the personal cc: version of this message I got.
> Here is what I said :
>
> It's a very interesting idea and would be powerful.
> My only concern is that Cordova apps can be built just by calling
> platform create scripts, with plugins added by calling plugman
> directly. The hooks are very specific to cordova-cli builds.
>
> Another approach would be to add platform level hooks that plugins
> could subscribe to, maybe just pre-build and post-build.
>
> And plugman level scripts for install/uninstall
>
> Then possibly even cordova-cli hooks that just trigger the underlying
> functions.
>
>
> @purplecabbage
> risingj.com
>
>
> On Sat, Mar 1, 2014 at 10:39 AM, Sergey Grebnov (Akvelon) <
> v-segreb@microsoft.com> wrote:
>
> > Hi, I have an idea how we can add more flexibility to plugin
> > developers and would like to discuss it.
> >
> > Note, right now we have Application Developers - someone who use
> > Cordova for developing applications and Plugin Developers - someone
> > who creates plugins so that Application Developers can use them. For
> > Application Developers we expose hooks so that they can customize
> > their build/package/etc process. I want us to provide similar sort
> > of
> flexibility
> > to Plugin Developers so that they can go beyond of <source/>,
> <framework/>
> > tags and get mechanism to add custom installation, build logic
> > required by a plugin. Example usage will include:
> > downloading/compiling additional binaries, marking source file to be
> > copied to output dir, changing target build platform, etc. At
> > present time the steps described could be only achieved by hooks
> > manually added by Application Developer, but the right way is to
> > allow Plugin Developer to expose this as part of plugin definition.
> >
> > I personally like how npm-scripts[1] work so propose to introduce
> > additional <scripts> section in plugin.xml, for example
> >
> > <scripts preinstall="preinstall.js" postinstall="afterinstall.js" />
> >
> > preinstall.js is called before plugman.raw.install(platform,
> platformRoot,
> > path.basename(dir), pluginsDir, options) and could be used to check
> system
> > requirements, download/compile required libraries, etc
> >
> > afterinstall.js is called after and could be used to add/configure
> > additional project references, etc uninstall.js - for discussion,
> > could be used for clean up, etc
> >
> > As for required parameters I think we should pass at least
> > application folder and target platform.
> >
> > Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014
> > (7pm
> > EST)
> >
> > [1] https://www.npmjs.org/doc/misc/npm-scripts.html
> >
> > -Sergey
> >
>
Re: Proposal: hooks support for plugins
Posted by Brian LeRoux <b...@brian.io>.
this capability is supported in npm (for which we base much of our plugin
thinking and src) so technically I don't see much issue and the use cases
are def there
On Mon, Mar 3, 2014 at 10:44 AM, Andrew Grieve <ag...@chromium.org> wrote:
> There's definitely a security angle to this. E.g. You install a plugin and
> now it's running code on your machine in a non-sandboxed way. Maybe could
> warn before running the script for the first time, or show a badge on its
> plugins.cordova.io page to highlight this.
>
> install hooks might make it harder to uninstall a plugin as well.
>
>
> On Sat, Mar 1, 2014 at 6:47 PM, Jesse <pu...@gmail.com> wrote:
>
> > I originally replied to the personal cc: version of this message I got.
> > Here is what I said :
> >
> > It's a very interesting idea and would be powerful.
> > My only concern is that Cordova apps can be built just by calling
> platform
> > create scripts, with plugins added by calling plugman directly. The hooks
> > are very specific to cordova-cli builds.
> >
> > Another approach would be to add platform level hooks that plugins could
> > subscribe to, maybe just pre-build and post-build.
> >
> > And plugman level scripts for install/uninstall
> >
> > Then possibly even cordova-cli hooks that just trigger the underlying
> > functions.
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Sat, Mar 1, 2014 at 10:39 AM, Sergey Grebnov (Akvelon) <
> > v-segreb@microsoft.com> wrote:
> >
> > > Hi, I have an idea how we can add more flexibility to plugin developers
> > > and would like to discuss it.
> > >
> > > Note, right now we have Application Developers - someone who use
> Cordova
> > > for developing applications and Plugin Developers - someone who creates
> > > plugins so that Application Developers can use them. For Application
> > > Developers we expose hooks so that they can customize their
> > > build/package/etc process. I want us to provide similar sort of
> > flexibility
> > > to Plugin Developers so that they can go beyond of <source/>,
> > <framework/>
> > > tags and get mechanism to add custom installation, build logic
> required
> > > by a plugin. Example usage will include: downloading/compiling
> additional
> > > binaries, marking source file to be copied to output dir, changing
> target
> > > build platform, etc. At present time the steps described could be only
> > > achieved by hooks manually added by Application Developer, but the
> right
> > > way is to allow Plugin Developer to expose this as part of plugin
> > > definition.
> > >
> > > I personally like how npm-scripts[1] work so propose to introduce
> > > additional <scripts> section in plugin.xml, for example
> > >
> > > <scripts preinstall="preinstall.js" postinstall="afterinstall.js" />
> > >
> > > preinstall.js is called before plugman.raw.install(platform,
> > platformRoot,
> > > path.basename(dir), pluginsDir, options) and could be used to check
> > system
> > > requirements, download/compile required libraries, etc
> > >
> > > afterinstall.js is called after and could be used to add/configure
> > > additional project references, etc
> > > uninstall.js - for discussion, could be used for clean up, etc
> > >
> > > As for required parameters I think we should pass at least application
> > > folder and target platform.
> > >
> > > Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014 (7pm
> > > EST)
> > >
> > > [1] https://www.npmjs.org/doc/misc/npm-scripts.html
> > >
> > > -Sergey
> > >
> >
>
Re: Proposal: hooks support for plugins
Posted by Andrew Grieve <ag...@chromium.org>.
There's definitely a security angle to this. E.g. You install a plugin and
now it's running code on your machine in a non-sandboxed way. Maybe could
warn before running the script for the first time, or show a badge on its
plugins.cordova.io page to highlight this.
install hooks might make it harder to uninstall a plugin as well.
On Sat, Mar 1, 2014 at 6:47 PM, Jesse <pu...@gmail.com> wrote:
> I originally replied to the personal cc: version of this message I got.
> Here is what I said :
>
> It's a very interesting idea and would be powerful.
> My only concern is that Cordova apps can be built just by calling platform
> create scripts, with plugins added by calling plugman directly. The hooks
> are very specific to cordova-cli builds.
>
> Another approach would be to add platform level hooks that plugins could
> subscribe to, maybe just pre-build and post-build.
>
> And plugman level scripts for install/uninstall
>
> Then possibly even cordova-cli hooks that just trigger the underlying
> functions.
>
>
> @purplecabbage
> risingj.com
>
>
> On Sat, Mar 1, 2014 at 10:39 AM, Sergey Grebnov (Akvelon) <
> v-segreb@microsoft.com> wrote:
>
> > Hi, I have an idea how we can add more flexibility to plugin developers
> > and would like to discuss it.
> >
> > Note, right now we have Application Developers - someone who use Cordova
> > for developing applications and Plugin Developers - someone who creates
> > plugins so that Application Developers can use them. For Application
> > Developers we expose hooks so that they can customize their
> > build/package/etc process. I want us to provide similar sort of
> flexibility
> > to Plugin Developers so that they can go beyond of <source/>,
> <framework/>
> > tags and get mechanism to add custom installation, build logic required
> > by a plugin. Example usage will include: downloading/compiling additional
> > binaries, marking source file to be copied to output dir, changing target
> > build platform, etc. At present time the steps described could be only
> > achieved by hooks manually added by Application Developer, but the right
> > way is to allow Plugin Developer to expose this as part of plugin
> > definition.
> >
> > I personally like how npm-scripts[1] work so propose to introduce
> > additional <scripts> section in plugin.xml, for example
> >
> > <scripts preinstall="preinstall.js" postinstall="afterinstall.js" />
> >
> > preinstall.js is called before plugman.raw.install(platform,
> platformRoot,
> > path.basename(dir), pluginsDir, options) and could be used to check
> system
> > requirements, download/compile required libraries, etc
> >
> > afterinstall.js is called after and could be used to add/configure
> > additional project references, etc
> > uninstall.js - for discussion, could be used for clean up, etc
> >
> > As for required parameters I think we should pass at least application
> > folder and target platform.
> >
> > Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014 (7pm
> > EST)
> >
> > [1] https://www.npmjs.org/doc/misc/npm-scripts.html
> >
> > -Sergey
> >
>
Re: Proposal: hooks support for plugins
Posted by Jesse <pu...@gmail.com>.
I originally replied to the personal cc: version of this message I got.
Here is what I said :
It's a very interesting idea and would be powerful.
My only concern is that Cordova apps can be built just by calling platform
create scripts, with plugins added by calling plugman directly. The hooks
are very specific to cordova-cli builds.
Another approach would be to add platform level hooks that plugins could
subscribe to, maybe just pre-build and post-build.
And plugman level scripts for install/uninstall
Then possibly even cordova-cli hooks that just trigger the underlying
functions.
@purplecabbage
risingj.com
On Sat, Mar 1, 2014 at 10:39 AM, Sergey Grebnov (Akvelon) <
v-segreb@microsoft.com> wrote:
> Hi, I have an idea how we can add more flexibility to plugin developers
> and would like to discuss it.
>
> Note, right now we have Application Developers - someone who use Cordova
> for developing applications and Plugin Developers - someone who creates
> plugins so that Application Developers can use them. For Application
> Developers we expose hooks so that they can customize their
> build/package/etc process. I want us to provide similar sort of flexibility
> to Plugin Developers so that they can go beyond of <source/>, <framework/>
> tags and get mechanism to add custom installation, build logic required
> by a plugin. Example usage will include: downloading/compiling additional
> binaries, marking source file to be copied to output dir, changing target
> build platform, etc. At present time the steps described could be only
> achieved by hooks manually added by Application Developer, but the right
> way is to allow Plugin Developer to expose this as part of plugin
> definition.
>
> I personally like how npm-scripts[1] work so propose to introduce
> additional <scripts> section in plugin.xml, for example
>
> <scripts preinstall="preinstall.js" postinstall="afterinstall.js" />
>
> preinstall.js is called before plugman.raw.install(platform, platformRoot,
> path.basename(dir), pluginsDir, options) and could be used to check system
> requirements, download/compile required libraries, etc
>
> afterinstall.js is called after and could be used to add/configure
> additional project references, etc
> uninstall.js - for discussion, could be used for clean up, etc
>
> As for required parameters I think we should pass at least application
> folder and target platform.
>
> Thoughts? Propose to discuss this on the monthly sync, Mar 4, 2014 (7pm
> EST)
>
> [1] https://www.npmjs.org/doc/misc/npm-scripts.html
>
> -Sergey
>