Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of agrieve@google.com designates
 209.85.214.169 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CADVgkyNNA3ufKJhvoApp9+9SsaXJ2z57hAXpgGDYbN0X65e7-A@mail.gmail.com>
References: 
 <CANpVHHwC5GLOCennHc2y1r+Bv+xcr5jeAiMBicHEF+VnEZbXeg@mail.gmail.com>
 <CAEeF2Tf2ESKcE3ODRugm5wB8Hbyd40L3ThH6aMY-R6N0h4xkSg@mail.gmail.com>
 <CANpVHHzP7afj1tyDHx3Y5TLB0ArdNrq5hZMy9WGaDE1-ay3WNw@mail.gmail.com>
 <CAEeF2Tf7kqk6FWZ7wUY4d+BONrw7nA+GRgyvBmA_XOqiEUxR_g@mail.gmail.com>
 <CADVgkyM15CFhRVxQ6Qe6SBzk7UVraqu86ExvRmPhHOo4+gQO_Q@mail.gmail.com>
 <CABiQX1U-hF1FZ+eqCNe-utEosPO_1YQoGOXgOj_hRw9y=shvTg@mail.gmail.com>
 <CANpVHHyHVU4usK=2jBgcWMQJP0SB5n+DjAC+GWGQC_-vWzFUsw@mail.gmail.com>
 <CAKP6k2toxx3pmTOD5xc2i_H2F4jaRPJntntMfv3PY+cKUo-a5g@mail.gmail.com>
 <CADVgkyNNA3ufKJhvoApp9+9SsaXJ2z57hAXpgGDYbN0X65e7-A@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Wed, 9 Apr 2014 06:41:12 -0800
Message-ID: 
 <CABiQX1XXEoo4ojBtN+_VtzP_2gszWna6O9JLGzjKYg4_8pP2eA@mail.gmail.com>
Subject: Re: [cordova-js] do we need <clobbers/>, <merges/> ?
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11c257a4cb7fe804f69d1876

--001a11c257a4cb7fe804f69d1876
Content-Type: text/plain; charset=UTF-8

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 <purplecabbage@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 <anis.kadri@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" <mmocny@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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--001a11c257a4cb7fe804f69d1876--