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/04/18 02:19:10 UTC
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 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.