[cordova-js] do we need , ?

[Anis KADRI <an...@gmail.com>]

and I mean the tags. plugins should be able to clobber/merge the window (or
any other context) if they need to. We can advise developers to use our
builder module that does just that or they can write their own
clobber/merges code.

RE: [cordova-js] do we need , ?

[Jonathan Bond-Caron <jb...@gdesolutions.com>]

On Thu Apr 10 01:35 PM, Michal Mocny wrote:
> 
> List of hangouts scheduled:
> https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes
> Agenda for this next one: https://wiki.apache.org/cordova/Agenda20140415
> 

Awesome, I'll join in

Cheers,
Jon

Re: [cordova-js] do we need , ?

[Michal Mocny <mm...@chromium.org>]

On Thu, Apr 10, 2014 at 1:07 PM, Anis KADRI <an...@gmail.com> wrote:

> On Thu, Apr 10, 2014 at 8:18 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Alright, this thread is starting to run away, I think.
> >
> > We have a G+ Hangout scheduled for next week.  This looks like a great
> > topic to discuss.  Generally, I think we should resolve these disputes
> the
> > only way that makes real sense: produce a set of test cases that work
> today
> > and that we want to continue to work after this change and hand them over
> > to Anis/Brian.  That way we can be tangible with our arguments.  We'll do
> > that from our end in prep for next week.
> >
>
> Yes! That is exactly what I have been asking for :-)
>
>
> >
> > (I think some of the friction here comes because this isn't seen as a
> pain
> > point / priority, and so aversion to change kicks in.  However,
> Anis/Brian
> > seem excited about it and have put in the leg work, and that certainly
> > meets my bar for acceptance.)
> >
> > So, lets leave the discussion for next Tuesday at the Hangout.  Come with
> > use cases.
> >
>
> Looking forward to this. Do we have a a shared agenda somewhere yet ?
>

List of hangouts scheduled:
https://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes
Agenda for this next one: https://wiki.apache.org/cordova/Agenda20140415


>
> >
> > -Michal
> >
> >
> > On Thu, Apr 10, 2014 at 9:10 AM, Jonathan Bond-Caron <
> > jbondc@gdesolutions.com> wrote:
> >
> > > On Wed Apr 9 08:40 PM, Brian LeRoux wrote:
> > > >
> > > > The cons are wrong. You can import plugins and indeed you can test
> > > plugins.
> > > > The statement that we shouldn't need to compile/transpile is not
> > correct
> > > if we
> > > > want to evolve things. Its the only path we have that will keep
> things
> > > backwards
> > > > compatible. (That we could determine.)
> > >
> > > I put up an example here:
> > >
> > >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt
> > >
> > > The cons were against the current plugin.xml & <clobbers/>, <merges/>
> > > To be clear, it's a pro for using something like browserify.
> > >
> > > If part of the net benefit is we can have a story like:
> > > cordova create plugin file.encrypt
> > >
> > >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/package.json
> > >
> > > Extend existing plugin:
> > >
> > >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem-es6.js
> > >
> > > cordova plugin test <--- this (runs in some bleeding edge browser)
> > >
> > > That's a big win / net benefit for being more opiniated about the
> module
> > > format.
> > >
> > > The browserify node.js story looks like:
> > >
> > >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem.js
> > >
> > > But trying to bring the entire node.js api *into* the browser is a big
> > > hack, turning an apple into an orange.
> > >
> >
>

Re: [cordova-js] do we need , ?

[Anis KADRI <an...@gmail.com>]

On Thu, Apr 10, 2014 at 8:18 AM, Michal Mocny <mm...@chromium.org> wrote:

> Alright, this thread is starting to run away, I think.
>
> We have a G+ Hangout scheduled for next week.  This looks like a great
> topic to discuss.  Generally, I think we should resolve these disputes the
> only way that makes real sense: produce a set of test cases that work today
> and that we want to continue to work after this change and hand them over
> to Anis/Brian.  That way we can be tangible with our arguments.  We'll do
> that from our end in prep for next week.
>

Yes! That is exactly what I have been asking for :-)


>
> (I think some of the friction here comes because this isn't seen as a pain
> point / priority, and so aversion to change kicks in.  However, Anis/Brian
> seem excited about it and have put in the leg work, and that certainly
> meets my bar for acceptance.)
>
> So, lets leave the discussion for next Tuesday at the Hangout.  Come with
> use cases.
>

Looking forward to this. Do we have a a shared agenda somewhere yet ?


>
> -Michal
>
>
> On Thu, Apr 10, 2014 at 9:10 AM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Wed Apr 9 08:40 PM, Brian LeRoux wrote:
> > >
> > > The cons are wrong. You can import plugins and indeed you can test
> > plugins.
> > > The statement that we shouldn't need to compile/transpile is not
> correct
> > if we
> > > want to evolve things. Its the only path we have that will keep things
> > backwards
> > > compatible. (That we could determine.)
> >
> > I put up an example here:
> >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt
> >
> > The cons were against the current plugin.xml & <clobbers/>, <merges/>
> > To be clear, it's a pro for using something like browserify.
> >
> > If part of the net benefit is we can have a story like:
> > cordova create plugin file.encrypt
> >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/package.json
> >
> > Extend existing plugin:
> >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem-es6.js
> >
> > cordova plugin test <--- this (runs in some bleeding edge browser)
> >
> > That's a big win / net benefit for being more opiniated about the module
> > format.
> >
> > The browserify node.js story looks like:
> >
> >
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem.js
> >
> > But trying to bring the entire node.js api *into* the browser is a big
> > hack, turning an apple into an orange.
> >
>

Re: [cordova-js] do we need , ?

[Michal Mocny <mm...@chromium.org>]

Alright, this thread is starting to run away, I think.

We have a G+ Hangout scheduled for next week.  This looks like a great
topic to discuss.  Generally, I think we should resolve these disputes the
only way that makes real sense: produce a set of test cases that work today
and that we want to continue to work after this change and hand them over
to Anis/Brian.  That way we can be tangible with our arguments.  We'll do
that from our end in prep for next week.

(I think some of the friction here comes because this isn't seen as a pain
point / priority, and so aversion to change kicks in.  However, Anis/Brian
seem excited about it and have put in the leg work, and that certainly
meets my bar for acceptance.)

So, lets leave the discussion for next Tuesday at the Hangout.  Come with
use cases.

-Michal


On Thu, Apr 10, 2014 at 9:10 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:

> On Wed Apr 9 08:40 PM, Brian LeRoux wrote:
> >
> > The cons are wrong. You can import plugins and indeed you can test
> plugins.
> > The statement that we shouldn't need to compile/transpile is not correct
> if we
> > want to evolve things. Its the only path we have that will keep things
> backwards
> > compatible. (That we could determine.)
>
> I put up an example here:
>
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt
>
> The cons were against the current plugin.xml & <clobbers/>, <merges/>
> To be clear, it's a pro for using something like browserify.
>
> If part of the net benefit is we can have a story like:
> cordova create plugin file.encrypt
>
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/package.json
>
> Extend existing plugin:
>
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem-es6.js
>
> cordova plugin test <--- this (runs in some bleeding edge browser)
>
> That's a big win / net benefit for being more opiniated about the module
> format.
>
> The browserify node.js story looks like:
>
> https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem.js
>
> But trying to bring the entire node.js api *into* the browser is a big
> hack, turning an apple into an orange.
>

RE: [cordova-js] do we need , ?

[Jonathan Bond-Caron <jb...@gdesolutions.com>]

On Wed Apr 9 08:40 PM, Brian LeRoux wrote:
> 
> The cons are wrong. You can import plugins and indeed you can test plugins.
> The statement that we shouldn't need to compile/transpile is not correct if we
> want to evolve things. Its the only path we have that will keep things backwards
> compatible. (That we could determine.) 

I put up an example here:
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt

The cons were against the current plugin.xml & <clobbers/>, <merges/>
To be clear, it's a pro for using something like browserify.

If part of the net benefit is we can have a story like:
cordova create plugin file.encrypt
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/package.json

Extend existing plugin:
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem-es6.js

cordova plugin test <--- this (runs in some bleeding edge browser)

That's a big win / net benefit for being more opiniated about the module format.

The browserify node.js story looks like:
https://github.com/gdesolutions/ja-lib/tree/master/tests/plugins/file.encrypt/LocalFileSystem.js

But trying to bring the entire node.js api *into* the browser is a big hack, turning an apple into an orange.

Re: [cordova-js] do we need , ?

[Brian LeRoux <b...@brian.io>]

As they say: patches welcome. We didn't just pick Browserify without
thinking this through: with code. From my perspective using an external
tool focused on the problem that is battle hardened is better than
maintaining our own and Browserify is the best of the bunch.

I don't care if it has many dependencies so long as it itself is tested
well. Agree, ES6 modules would be great but that is not happening anytime
soon for the mobile web. Webpack solves the problem without having an
opinion, a great deal of optional config, making it fragile (imo). I'm not
a fan requirejs (or indeed amd in general) for cases wherein we just concat
to a single file and load it once anyhow negating its only promise.

The cons are wrong. You can import plugins and indeed you can test plugins.
The statement that we shouldn't need to compile/transpile is not correct if
we want to evolve things. Its the only path we have that will keep things
backwards compatible. (That we could determine.) Again, we welcome a branch
that demonstrates alternatives.


On Thu, Apr 10, 2014 at 9:55 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:

> On Tue Apr 8 03:50 PM, Andrew Grieve wrote:
> >
> > The question of whether we *need* them is not a good way to phrase it I
> think.
> > Rather:
> > Pros?
>
> - Cordova doesn't pick a style of writing modules/plugins
> - More control over how plugin loading works
>
> Prefer this approach for now, might be a better way to do this eventually:
> https://plus.google.com/+PaulIrish/posts/cHLhcSfJyJo
>
> Good points by Alex Young, James Burke
>
> > Cons?
>
> - No way to require() or import() other plugins, e.g. extend a plugin
> - Difficult to "test" cordova plugins
> - Shouldn't need to compile/transform/transpile a plugin to test it
>
> > Worth changing at this point?
>
> Not a fan of any 'bundling' tool with so many dependencies:
> https://github.com/substack/node-browserify/blob/master/package.json
> https://github.com/webpack/webpack/blob/master/package.json
>
> The ES6 web modules situation is evolving, but still messy:
> https://github.com/addyosmani/es6-tools
>
> Seems better to experiment more
>

Re: [cordova-js] do we need , ?

[Anis KADRI <an...@gmail.com>]

On Wed, Apr 9, 2014 at 4:55 PM, Jonathan Bond-Caron <jbondc@gdesolutions.com
> wrote:

> On Tue Apr 8 03:50 PM, Andrew Grieve wrote:
> >
> > The question of whether we *need* them is not a good way to phrase it I
> think.
> > Rather:
> > Pros?
>
> - Cordova doesn't pick a style of writing modules/plugins
> - More control over how plugin loading works
>
> Prefer this approach for now, might be a better way to do this eventually:
> https://plus.google.com/+PaulIrish/posts/cHLhcSfJyJo
>
> Good points by Alex Young, James Burke
>
> > Cons?
>
> - No way to require() or import() other plugins, e.g. extend a plugin
>

Can you please clarify (with an example)?


> - Difficult to "test" cordova plugins
>

Can you please clarify (with an example)?


> - Shouldn't need to compile/transform/transpile a plugin to test it
>

This is a temporary solution to make existing plugins work without
modification.


>
> > Worth changing at this point?
>
> Not a fan of any 'bundling' tool with so many dependencies:
> https://github.com/substack/node-browserify/blob/master/package.json
> https://github.com/webpack/webpack/blob/master/package.json
>
>
This is a fair statement but I'd rather delegate to simplify than reinvent
the wheel (and leave it to rust). Those two seem like they could be the
right solution for now. If there are (or will be) better bundling tools out
there they hopefully (will) support node/commonJS and we won't have to
change our current plugins implementation.


> The ES6 web modules situation is evolving, but still messy:
> https://github.com/addyosmani/es6-tools
>
> Seems better to experiment more
>

RE: [cordova-js] do we need , ?

[Jonathan Bond-Caron <jb...@gdesolutions.com>]

On Tue Apr 8 03:50 PM, Andrew Grieve wrote:
> 
> The question of whether we *need* them is not a good way to phrase it I think.
> Rather:
> Pros? 

- Cordova doesn't pick a style of writing modules/plugins
- More control over how plugin loading works

Prefer this approach for now, might be a better way to do this eventually:
https://plus.google.com/+PaulIrish/posts/cHLhcSfJyJo

Good points by Alex Young, James Burke

> Cons? 

- No way to require() or import() other plugins, e.g. extend a plugin
- Difficult to "test" cordova plugins 
- Shouldn't need to compile/transform/transpile a plugin to test it

> Worth changing at this point?

Not a fan of any 'bundling' tool with so many dependencies:
https://github.com/substack/node-browserify/blob/master/package.json
https://github.com/webpack/webpack/blob/master/package.json

The ES6 web modules situation is evolving, but still messy:
https://github.com/addyosmani/es6-tools

Seems better to experiment more

Re: [cordova-js] do we need , ?

[Anis KADRI <an...@gmail.com>]

On Wed, Apr 9, 2014 at 7:41 AM, Andrew Grieve <ag...@chromium.org> wrote:

> It's a change of semantics. We can't just dump them. I'll admit that the
> syntax is confusing - we've already discussed making it a bit nicer and
> there's an old bug for making it more obvious.
>

I think we should make them inexistant and then it doesn't have to be
obvious.


>
> *But* - less code - no, now there's more code in every plugin.
>

If we made clobber/merges a lib, there would be one or two lines to add at
the bottom of each module. Two lines is not what I consider a lot of code.


> Less complexity? This is subjective.
>

If those tags don't exist, plugin.xml becomes a tad simpler.


> Is this even worth putting our time into? Is this addressing a problem? I
> don't think so, but that's just my opinion.
>

Yes. The problem being that as much as clobber/merges are needed, their
respective declarative tags are not.


>
> One common usage of <runs/> is to have a module tell cordova not to fire
> deviceready until the plugin says it's ready. For app-harness, this change
> will add significant complexity, because instead right now we include all
> modules (even for those the app we're launching doesn't want), and that's a
> harmless thing to do. If things change so that all modules are executed on
> start-up, we'll have to re-package at runtime our version of cordova.js.
>

This is a good point to add to the other thread. This thread is only for
clobber and merges.

>
>
> On Tue, Apr 8, 2014 at 2:20 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > I agree. And less code!
> >
> >
> > On Wed, Apr 9, 2014 at 7:24 AM, Jesse <pu...@gmail.com> wrote:
> >
> > > Dump them, I see no use for a declarative level of indirection.
> > >
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Tue, Apr 8, 2014 at 2:15 PM, Anis KADRI <an...@gmail.com>
> wrote:
> > >
> > > > On Tue, Apr 8, 2014 at 12:50 PM, Andrew Grieve <agrieve@chromium.org
> >
> > > > wrote:
> > > >
> > > > > I think symbol mapping comes with some nuances, and having the them
> > in
> > > a
> > > > > declarative way makes it easier than telling all plugins to write
> > their
> > > > JS
> > > > > in a certain way.
> > > >
> > > >
> > > > Makes what "exactly" easier ?
> > > >
> > > >
> > > > > It's a level of indirection that gives us the ability to
> > > > > control exactly *when* the mapping happens for example.
> > > > >
> > > >
> > > > Why does this matter ?
> > > >
> > > >
> > > > >
> > > > > The question of whether we *need* them is not a good way to phrase
> > it I
> > > > > think. Rather:
> > > > > Pros? Cons? Worth changing at this point?
> > > > >
> > > >
> > > > Pros: I don't see any. Like Michal suggested in another post, I see
> the
> > > > benefit of having a lib (builder.js) that clobbers/merges namespaces
> > that
> > > > plugins could consume. I don't see the benefits of dedicated XML
> tags.
> > > >
> > > > Cons:
> > > >
> > > > Unnecessary complexity
> > > >
> > > > It is not worth changing. Just worth dropping support for in my
> > opinion.
> > > > And not now but 6 months after we decide to do it.
> > > >
> > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Apr 5, 2014 at 10:56 AM, Brian LeRoux <b...@brian.io> wrote:
> > > > >
> > > > > > +1
> > > > > > On Apr 4, 2014 10:22 PM, "Michal Mocny" <mm...@chromium.org>
> > wrote:
> > > > > >
> > > > > > > To be clear: support for the tags is needed for plugins to work
> > as
> > > > they
> > > > > > do
> > > > > > > now.
> > > > > > >
> > > > > > > I'm optimistic that we could replacing them with a library, but
> > > > Andrew
> > > > > > had
> > > > > > > a few good points in the other thread for us to make sure we
> > don't
> > > > > > > overlook.
> > > > > > >
> > > > > > > Lets just prototype it on the core plugins, shall we?
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <
> > anis.kadri@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Yes the library exists (it's common/builder.js) and it can be
> > > used
> > > > by
> > > > > > > > plugins and yes it runs on startup automatically (unless we
> > tell
> > > it
> > > > > not
> > > > > > > > too) by require()ing the library and calling the appropriate
> > > > method.
> > > > > So
> > > > > > > do
> > > > > > > > you agree that the tags are not needed then ?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <
> > > mmocny@chromium.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > As commented in another thread, these are super useful,
> but I
> > > see
> > > > > > some
> > > > > > > > hope
> > > > > > > > > to replacing them with a library instead of tooling
> support.
> > >  We
> > > > > > would
> > > > > > > > > still need to run these automatically on startup somehow.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <
> > > anis.kadri@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > and I mean the tags. plugins should be able to
> > clobber/merge
> > > > the
> > > > > > > window
> > > > > > > > > (or
> > > > > > > > > > any other context) if they need to. We can advise
> > developers
> > > to
> > > > > use
> > > > > > > our
> > > > > > > > > > builder module that does just that or they can write
> their
> > > own
> > > > > > > > > > clobber/merges code.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [cordova-js] do we need , ?

[Andrew Grieve <ag...@chromium.org>]

It's a change of semantics. We can't just dump them. I'll admit that the
syntax is confusing - we've already discussed making it a bit nicer and
there's an old bug for making it more obvious.

*But* - less code - no, now there's more code in every plugin.
Less complexity? This is subjective.
Is this even worth putting our time into? Is this addressing a problem? I
don't think so, but that's just my opinion.

One common usage of <runs/> is to have a module tell cordova not to fire
deviceready until the plugin says it's ready. For app-harness, this change
will add significant complexity, because instead right now we include all
modules (even for those the app we're launching doesn't want), and that's a
harmless thing to do. If things change so that all modules are executed on
start-up, we'll have to re-package at runtime our version of cordova.js.


On Tue, Apr 8, 2014 at 2:20 PM, Brian LeRoux <b...@brian.io> wrote:

> I agree. And less code!
>
>
> On Wed, Apr 9, 2014 at 7:24 AM, Jesse <pu...@gmail.com> wrote:
>
> > Dump them, I see no use for a declarative level of indirection.
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Tue, Apr 8, 2014 at 2:15 PM, Anis KADRI <an...@gmail.com> wrote:
> >
> > > On Tue, Apr 8, 2014 at 12:50 PM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > >
> > > > I think symbol mapping comes with some nuances, and having the them
> in
> > a
> > > > declarative way makes it easier than telling all plugins to write
> their
> > > JS
> > > > in a certain way.
> > >
> > >
> > > Makes what "exactly" easier ?
> > >
> > >
> > > > It's a level of indirection that gives us the ability to
> > > > control exactly *when* the mapping happens for example.
> > > >
> > >
> > > Why does this matter ?
> > >
> > >
> > > >
> > > > The question of whether we *need* them is not a good way to phrase
> it I
> > > > think. Rather:
> > > > Pros? Cons? Worth changing at this point?
> > > >
> > >
> > > Pros: I don't see any. Like Michal suggested in another post, I see the
> > > benefit of having a lib (builder.js) that clobbers/merges namespaces
> that
> > > plugins could consume. I don't see the benefits of dedicated XML tags.
> > >
> > > Cons:
> > >
> > > Unnecessary complexity
> > >
> > > It is not worth changing. Just worth dropping support for in my
> opinion.
> > > And not now but 6 months after we decide to do it.
> > >
> > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Apr 5, 2014 at 10:56 AM, Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > > > +1
> > > > > On Apr 4, 2014 10:22 PM, "Michal Mocny" <mm...@chromium.org>
> wrote:
> > > > >
> > > > > > To be clear: support for the tags is needed for plugins to work
> as
> > > they
> > > > > do
> > > > > > now.
> > > > > >
> > > > > > I'm optimistic that we could replacing them with a library, but
> > > Andrew
> > > > > had
> > > > > > a few good points in the other thread for us to make sure we
> don't
> > > > > > overlook.
> > > > > >
> > > > > > Lets just prototype it on the core plugins, shall we?
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <
> anis.kadri@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Yes the library exists (it's common/builder.js) and it can be
> > used
> > > by
> > > > > > > plugins and yes it runs on startup automatically (unless we
> tell
> > it
> > > > not
> > > > > > > too) by require()ing the library and calling the appropriate
> > > method.
> > > > So
> > > > > > do
> > > > > > > you agree that the tags are not needed then ?
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <
> > mmocny@chromium.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > > As commented in another thread, these are super useful, but I
> > see
> > > > > some
> > > > > > > hope
> > > > > > > > to replacing them with a library instead of tooling support.
> >  We
> > > > > would
> > > > > > > > still need to run these automatically on startup somehow.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <
> > anis.kadri@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > and I mean the tags. plugins should be able to
> clobber/merge
> > > the
> > > > > > window
> > > > > > > > (or
> > > > > > > > > any other context) if they need to. We can advise
> developers
> > to
> > > > use
> > > > > > our
> > > > > > > > > builder module that does just that or they can write their
> > own
> > > > > > > > > clobber/merges code.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [cordova-js] do we need , ?

[Brian LeRoux <b...@brian.io>]

I agree. And less code!


On Wed, Apr 9, 2014 at 7:24 AM, Jesse <pu...@gmail.com> wrote:

> Dump them, I see no use for a declarative level of indirection.
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Apr 8, 2014 at 2:15 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > On Tue, Apr 8, 2014 at 12:50 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > I think symbol mapping comes with some nuances, and having the them in
> a
> > > declarative way makes it easier than telling all plugins to write their
> > JS
> > > in a certain way.
> >
> >
> > Makes what "exactly" easier ?
> >
> >
> > > It's a level of indirection that gives us the ability to
> > > control exactly *when* the mapping happens for example.
> > >
> >
> > Why does this matter ?
> >
> >
> > >
> > > The question of whether we *need* them is not a good way to phrase it I
> > > think. Rather:
> > > Pros? Cons? Worth changing at this point?
> > >
> >
> > Pros: I don't see any. Like Michal suggested in another post, I see the
> > benefit of having a lib (builder.js) that clobbers/merges namespaces that
> > plugins could consume. I don't see the benefits of dedicated XML tags.
> >
> > Cons:
> >
> > Unnecessary complexity
> >
> > It is not worth changing. Just worth dropping support for in my opinion.
> > And not now but 6 months after we decide to do it.
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > On Sat, Apr 5, 2014 at 10:56 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > +1
> > > > On Apr 4, 2014 10:22 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > >
> > > > > To be clear: support for the tags is needed for plugins to work as
> > they
> > > > do
> > > > > now.
> > > > >
> > > > > I'm optimistic that we could replacing them with a library, but
> > Andrew
> > > > had
> > > > > a few good points in the other thread for us to make sure we don't
> > > > > overlook.
> > > > >
> > > > > Lets just prototype it on the core plugins, shall we?
> > > > >
> > > > >
> > > > > On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <an...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > Yes the library exists (it's common/builder.js) and it can be
> used
> > by
> > > > > > plugins and yes it runs on startup automatically (unless we tell
> it
> > > not
> > > > > > too) by require()ing the library and calling the appropriate
> > method.
> > > So
> > > > > do
> > > > > > you agree that the tags are not needed then ?
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <
> mmocny@chromium.org>
> > > > > wrote:
> > > > > >
> > > > > > > As commented in another thread, these are super useful, but I
> see
> > > > some
> > > > > > hope
> > > > > > > to replacing them with a library instead of tooling support.
>  We
> > > > would
> > > > > > > still need to run these automatically on startup somehow.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <
> anis.kadri@gmail.com
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > > and I mean the tags. plugins should be able to clobber/merge
> > the
> > > > > window
> > > > > > > (or
> > > > > > > > any other context) if they need to. We can advise developers
> to
> > > use
> > > > > our
> > > > > > > > builder module that does just that or they can write their
> own
> > > > > > > > clobber/merges code.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [cordova-js] do we need , ?

[Jesse <pu...@gmail.com>]

Dump them, I see no use for a declarative level of indirection.




@purplecabbage
risingj.com


On Tue, Apr 8, 2014 at 2:15 PM, Anis KADRI <an...@gmail.com> wrote:

> On Tue, Apr 8, 2014 at 12:50 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > I think symbol mapping comes with some nuances, and having the them in a
> > declarative way makes it easier than telling all plugins to write their
> JS
> > in a certain way.
>
>
> Makes what "exactly" easier ?
>
>
> > It's a level of indirection that gives us the ability to
> > control exactly *when* the mapping happens for example.
> >
>
> Why does this matter ?
>
>
> >
> > The question of whether we *need* them is not a good way to phrase it I
> > think. Rather:
> > Pros? Cons? Worth changing at this point?
> >
>
> Pros: I don't see any. Like Michal suggested in another post, I see the
> benefit of having a lib (builder.js) that clobbers/merges namespaces that
> plugins could consume. I don't see the benefits of dedicated XML tags.
>
> Cons:
>
> Unnecessary complexity
>
> It is not worth changing. Just worth dropping support for in my opinion.
> And not now but 6 months after we decide to do it.
>
>
> >
> >
> >
> >
> >
> > On Sat, Apr 5, 2014 at 10:56 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > +1
> > > On Apr 4, 2014 10:22 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> > >
> > > > To be clear: support for the tags is needed for plugins to work as
> they
> > > do
> > > > now.
> > > >
> > > > I'm optimistic that we could replacing them with a library, but
> Andrew
> > > had
> > > > a few good points in the other thread for us to make sure we don't
> > > > overlook.
> > > >
> > > > Lets just prototype it on the core plugins, shall we?
> > > >
> > > >
> > > > On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <an...@gmail.com>
> > > wrote:
> > > >
> > > > > Yes the library exists (it's common/builder.js) and it can be used
> by
> > > > > plugins and yes it runs on startup automatically (unless we tell it
> > not
> > > > > too) by require()ing the library and calling the appropriate
> method.
> > So
> > > > do
> > > > > you agree that the tags are not needed then ?
> > > > >
> > > > >
> > > > > On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <mm...@chromium.org>
> > > > wrote:
> > > > >
> > > > > > As commented in another thread, these are super useful, but I see
> > > some
> > > > > hope
> > > > > > to replacing them with a library instead of tooling support.  We
> > > would
> > > > > > still need to run these automatically on startup somehow.
> > > > > >
> > > > > >
> > > > > > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <anis.kadri@gmail.com
> >
> > > > wrote:
> > > > > >
> > > > > > > and I mean the tags. plugins should be able to clobber/merge
> the
> > > > window
> > > > > > (or
> > > > > > > any other context) if they need to. We can advise developers to
> > use
> > > > our
> > > > > > > builder module that does just that or they can write their own
> > > > > > > clobber/merges code.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [cordova-js] do we need , ?

[Anis KADRI <an...@gmail.com>]

On Tue, Apr 8, 2014 at 12:50 PM, Andrew Grieve <ag...@chromium.org> wrote:

> I think symbol mapping comes with some nuances, and having the them in a
> declarative way makes it easier than telling all plugins to write their JS
> in a certain way.


Makes what "exactly" easier ?


> It's a level of indirection that gives us the ability to
> control exactly *when* the mapping happens for example.
>

Why does this matter ?


>
> The question of whether we *need* them is not a good way to phrase it I
> think. Rather:
> Pros? Cons? Worth changing at this point?
>

Pros: I don't see any. Like Michal suggested in another post, I see the
benefit of having a lib (builder.js) that clobbers/merges namespaces that
plugins could consume. I don't see the benefits of dedicated XML tags.

Cons:

Unnecessary complexity

It is not worth changing. Just worth dropping support for in my opinion.
And not now but 6 months after we decide to do it.


>
>
>
>
>
> On Sat, Apr 5, 2014 at 10:56 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > +1
> > On Apr 4, 2014 10:22 PM, "Michal Mocny" <mm...@chromium.org> wrote:
> >
> > > To be clear: support for the tags is needed for plugins to work as they
> > do
> > > now.
> > >
> > > I'm optimistic that we could replacing them with a library, but Andrew
> > had
> > > a few good points in the other thread for us to make sure we don't
> > > overlook.
> > >
> > > Lets just prototype it on the core plugins, shall we?
> > >
> > >
> > > On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >
> > > > Yes the library exists (it's common/builder.js) and it can be used by
> > > > plugins and yes it runs on startup automatically (unless we tell it
> not
> > > > too) by require()ing the library and calling the appropriate method.
> So
> > > do
> > > > you agree that the tags are not needed then ?
> > > >
> > > >
> > > > On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >
> > > > > As commented in another thread, these are super useful, but I see
> > some
> > > > hope
> > > > > to replacing them with a library instead of tooling support.  We
> > would
> > > > > still need to run these automatically on startup somehow.
> > > > >
> > > > >
> > > > > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <an...@gmail.com>
> > > wrote:
> > > > >
> > > > > > and I mean the tags. plugins should be able to clobber/merge the
> > > window
> > > > > (or
> > > > > > any other context) if they need to. We can advise developers to
> use
> > > our
> > > > > > builder module that does just that or they can write their own
> > > > > > clobber/merges code.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [cordova-js] do we need , ?

[Andrew Grieve <ag...@chromium.org>]

I think symbol mapping comes with some nuances, and having the them in a
declarative way makes it easier than telling all plugins to write their JS
in a certain way. It's a level of indirection that gives us the ability to
control exactly *when* the mapping happens for example.

The question of whether we *need* them is not a good way to phrase it I
think. Rather:
Pros? Cons? Worth changing at this point?






On Sat, Apr 5, 2014 at 10:56 AM, Brian LeRoux <b...@brian.io> wrote:

> +1
> On Apr 4, 2014 10:22 PM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> > To be clear: support for the tags is needed for plugins to work as they
> do
> > now.
> >
> > I'm optimistic that we could replacing them with a library, but Andrew
> had
> > a few good points in the other thread for us to make sure we don't
> > overlook.
> >
> > Lets just prototype it on the core plugins, shall we?
> >
> >
> > On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >
> > > Yes the library exists (it's common/builder.js) and it can be used by
> > > plugins and yes it runs on startup automatically (unless we tell it not
> > > too) by require()ing the library and calling the appropriate method. So
> > do
> > > you agree that the tags are not needed then ?
> > >
> > >
> > > On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > As commented in another thread, these are super useful, but I see
> some
> > > hope
> > > > to replacing them with a library instead of tooling support.  We
> would
> > > > still need to run these automatically on startup somehow.
> > > >
> > > >
> > > > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > > >
> > > > > and I mean the tags. plugins should be able to clobber/merge the
> > window
> > > > (or
> > > > > any other context) if they need to. We can advise developers to use
> > our
> > > > > builder module that does just that or they can write their own
> > > > > clobber/merges code.
> > > > >
> > > >
> > >
> >
>

Re: [cordova-js] do we need , ?

[Brian LeRoux <b...@brian.io>]

+1
On Apr 4, 2014 10:22 PM, "Michal Mocny" <mm...@chromium.org> wrote:

> To be clear: support for the tags is needed for plugins to work as they do
> now.
>
> I'm optimistic that we could replacing them with a library, but Andrew had
> a few good points in the other thread for us to make sure we don't
> overlook.
>
> Lets just prototype it on the core plugins, shall we?
>
>
> On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > Yes the library exists (it's common/builder.js) and it can be used by
> > plugins and yes it runs on startup automatically (unless we tell it not
> > too) by require()ing the library and calling the appropriate method. So
> do
> > you agree that the tags are not needed then ?
> >
> >
> > On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > As commented in another thread, these are super useful, but I see some
> > hope
> > > to replacing them with a library instead of tooling support.  We would
> > > still need to run these automatically on startup somehow.
> > >
> > >
> > > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <an...@gmail.com>
> wrote:
> > >
> > > > and I mean the tags. plugins should be able to clobber/merge the
> window
> > > (or
> > > > any other context) if they need to. We can advise developers to use
> our
> > > > builder module that does just that or they can write their own
> > > > clobber/merges code.
> > > >
> > >
> >
>

Re: [cordova-js] do we need , ?

[Michal Mocny <mm...@chromium.org>]

To be clear: support for the tags is needed for plugins to work as they do
now.

I'm optimistic that we could replacing them with a library, but Andrew had
a few good points in the other thread for us to make sure we don't overlook.

Lets just prototype it on the core plugins, shall we?


On Fri, Apr 4, 2014 at 10:29 PM, Anis KADRI <an...@gmail.com> wrote:

> Yes the library exists (it's common/builder.js) and it can be used by
> plugins and yes it runs on startup automatically (unless we tell it not
> too) by require()ing the library and calling the appropriate method. So do
> you agree that the tags are not needed then ?
>
>
> On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > As commented in another thread, these are super useful, but I see some
> hope
> > to replacing them with a library instead of tooling support.  We would
> > still need to run these automatically on startup somehow.
> >
> >
> > On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <an...@gmail.com> wrote:
> >
> > > and I mean the tags. plugins should be able to clobber/merge the window
> > (or
> > > any other context) if they need to. We can advise developers to use our
> > > builder module that does just that or they can write their own
> > > clobber/merges code.
> > >
> >
>

Re: [cordova-js] do we need , ?

[Anis KADRI <an...@gmail.com>]

Yes the library exists (it's common/builder.js) and it can be used by
plugins and yes it runs on startup automatically (unless we tell it not
too) by require()ing the library and calling the appropriate method. So do
you agree that the tags are not needed then ?


On Fri, Apr 4, 2014 at 7:07 PM, Michal Mocny <mm...@chromium.org> wrote:

> As commented in another thread, these are super useful, but I see some hope
> to replacing them with a library instead of tooling support.  We would
> still need to run these automatically on startup somehow.
>
>
> On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > and I mean the tags. plugins should be able to clobber/merge the window
> (or
> > any other context) if they need to. We can advise developers to use our
> > builder module that does just that or they can write their own
> > clobber/merges code.
> >
>

Re: [cordova-js] do we need , ?

[Michal Mocny <mm...@chromium.org>]

As commented in another thread, these are super useful, but I see some hope
to replacing them with a library instead of tooling support.  We would
still need to run these automatically on startup somehow.


On Fri, Apr 4, 2014 at 8:48 PM, Anis KADRI <an...@gmail.com> wrote:

> and I mean the tags. plugins should be able to clobber/merge the window (or
> any other context) if they need to. We can advise developers to use our
> builder module that does just that or they can write their own
> clobber/merges code.
>