cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: <plugins> tag, and accessing the plugin list
Date Fri, 15 Nov 2013 20:48:50 GMT
Yup that is a sound plan. I think we should continue discussion on the
config file thing however. We have clearly accumulated some technical debt
here as it is difficult to reason (even describe) the config file dog pile.
Given the maturity of Cordova I feel paying off tech debt is crucially
important so we can keep adding new features without making everything
super brittle.


On Fri, Nov 15, 2013 at 10:48 AM, purplecabbage <purplecabbage@gmail.com>wrote:

> +1 to the short term fix and the deep dive punt
>
> Sent from my iPhone
>
> > On Nov 15, 2013, at 10:19 AM, Michal Mocny <mmocny@chromium.org> wrote:
> >
> > Hmm, sounds pretty un-intrusive.  Ship it!
> >
> > We should probably schedule a whole hack-a-thon for figuring out the
> future
> > of config files.  Maybe at our next face-to-face meetup, or just
> schedule a
> > hangout in the new year?
> >
> > -Michal
> >
> >
> >> On Fri, Nov 15, 2013 at 12:29 PM, Anis KADRI <anis.kadri@gmail.com>
> wrote:
> >>
> >> +1
> >>
> >> On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana <csantana23@gmail.com>
> >> wrote:
> >>> +1
> >>>
> >>> Yep I agree this way users can get list of plugins installed from
> >>> javascript pretty easy on all platforms from a web resource (i.e.
> >>> cordova_plugins.js
> >>> )
> >>>
> >>>
> >>> On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <agrieve@chromium.org
> >>> wrote:
> >>>
> >>>> That sounds good to me.
> >>>>
> >>>>
> >>>> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson <
> >> braden@chromium.org
> >>>>> wrote:
> >>>>
> >>>>> Looking back over all of this discussion, we have a growing trend
of
> >>>>> dissatisfaction with the current config file setup. We've talked
in
> >> the
> >>>>> past about moving to JSON format, Andrew is suggesting above
> replacing
> >>>> 99%
> >>>>> of <config-file> uses with specialized tags to inject permissions
and
> >>>>> <feature>s, my summary in the other thread was pretty disgustingly
> >>>>> complicated, etc.
> >>>>>
> >>>>> I propose three things:
> >>>>> 1. Punt all discussion of overhauling configuration files to the
new
> >>>> year.
> >>>>> 2. Drop my proposals above, as well as the summary Anis posted of
> last
> >>>>> night's discussion.
> >>>>> 3. Solve the immediate use-case of AppHarness wanting to know what
> >>>> plugins
> >>>>> are installed by injecting that object into a new key attached to
the
> >>>> array
> >>>>> of JS modules in cordova_plugins.js.
> >>>>>
> >>>>> This modifies a file that is already clearly a build artifact and
not
> >>>>> touched by humans. It is fully backward compatible, since the array
> >> of JS
> >>>>> modules is unchanged when viewed as an array. And it gets me access
> >> the
> >>>>> information I needed in the short term to build the AppHarness
> >>>>> functionality.
> >>>>>
> >>>>> How does that sound?
> >>>>>
> >>>>> Braden
> >>>>>
> >>>>>
> >>>>> On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <
> agrieve@chromium.org
> >>>>>> wrote:
> >>>>>
> >>>>>> I think the thing that irks me about the proposal to fiddle
with
> >>>>>> <feature>s, is that right now plugins put them in <config-file>
> >> tags.
> >>>>> With
> >>>>>> these tags:
> >>>>>>
> >>>>>> - You can specify any target that's an xml file
> >>>>>> - You can specify any xpath in the parent attribute
> >>>>>> - plugman will splice in your XML into the target file
> >> if-and-only-if
> >>>>> there
> >>>>>> wasn't already another plugin that spliced in the exact same
chunk
> >> into
> >>>>> the
> >>>>>> exact same place.
> >>>>>>
> >>>>>> Now, we're proposing to make this <config-file> rule even
more
> >> complex:
> >>>>>> - You can specify any target that's an xml file
> >>>>>> - You can specify any xpath in the parent attribute
> >>>>>> NEW:
> >>>>>> - If you specify target="config.xml" AND you specify parent
xpath
> >> that
> >>>>>> evaluates to the same things as parent="/widget" Then:
> >>>>>>   - For each top-level <feature> element in your payload:
> >>>>>>     - Plugman will insert two new <params> into it with
your plugin
> >>>> ID &
> >>>>>> version
> >>>>>> - plugman will splice in your XML into the target file
> >> if-and-only-if
> >>>>> there
> >>>>>> wasn't already another plugin that spliced in the exact same
chunk
> >> into
> >>>>> the
> >>>>>> exact same place.
> >>>>>> NEW:
> >>>>>> - If your plugin does not have any <config-file> targets
that match
> >> the
> >>>>>> above conditions:
> >>>>>>  - Plugman will add one for you with a default payload of a
> >> <feature>
> >>>>> with
> >>>>>> params.
> >>>>>>
> >>>>>>
> >>>>>> I haven't run it past any real-world users, but it if it sounds
> >>>>> complicated
> >>>>>> to me, then I'd be surprised if it wasn't also confusing to
others.
> >>>>>>
> >>>>>> Maybe a fallout of this discussion is that it's hurting us to
be
> >> using
> >>>>>> <config-file> for common things. Seems like it would be
simpler for
> >>>> both
> >>>>>> plugman and plugin devs to have <feature> outside of <config-file>.
> >> If
> >>>>> this
> >>>>>> were the case, I'd be much more open to the idea of altering
them
> >> when
> >>>> we
> >>>>>> spliced them in.
> >>>>>>
> >>>>>> Going a step further, Michal suggested in another thread that
we
> >> just
> >>>>>> include the plugin.xml files directly in apps. The more I think
> >> about
> >>>>> this,
> >>>>>> the more it makes sense to me. Why are we even splicing things
into
> >>>>>> config.xml? Seems like we're doing work to lose information.
If we
> >> just
> >>>>>> included the plugin.xml files directly, we could read out the
> >>>> <feature>,
> >>>>>> <access>, plugin iD & version, even <js-module>s.
If we want to keep
> >>>> all
> >>>>>> the runtime xml in one file, how about splice in the entire
> >> plugin.xml
> >>>>> into
> >>>>>> config.xml?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <anis.kadri@gmail.com
> >
> >>>>>> wrote:
> >>>>>>
> >>>>>>> On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <
> >> agrieve@chromium.org
> >>>>>
> >>>>>>> wrote:
> >>>>>>>> On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <
> >> anis.kadri@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> So...
> >>>>>>>>>
> >>>>>>>>> We just had a good chat about this topic with Braden
and Gorkem
> >>>> and
> >>>>> we
> >>>>>>>>> think that adding <param>s to the existing
<feature> tag is
> >> better
> >>>>>>>>> than introducing a new one.
> >>>>>>>>>
> >>>>>>>>> Pros:
> >>>>>>>>> - No new tags, less confusion.
> >>>>>>>>
> >>>>>>>> Unless we're going to add a new tag to do what <feature>
> >> currently
> >>>>>> does,
> >>>>>>>> I'd argue having one tag that does two things is more
confusing.
> >>>>>>>
> >>>>>>> As you say it's arguable but I tend to base my arguments
on
> >>>> real-world
> >>>>>>> users rather than Cordova core developers.
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> - A good path towards having a unique top-level config.xml
> >> since we
> >>>>>>>>> can now identify which plugins are installed from
the feature
> >> tag.
> >>>>>>>>> Therefore, we can better handle uninstalls and user
edits to
> >> the
> >>>>> file.
> >>>>>>>> This makes me think I just don't understand what the
proposal
> >> now
> >>>> is.
> >>>>>> An
> >>>>>>>> example would help I think.
> >>>>>>>> Some questions:
> >>>>>>>> - Does this mean we're going to change <feature>
to not directly
> >>>>> define
> >>>>>>>> bridge mappings?
> >>>>>>>
> >>>>>>> No
> >>>>>>>
> >>>>>>>>   - Is the idea to have a new tag within <feature>
that defines
> >>>> the
> >>>>>>> bridge
> >>>>>>>> binding?
> >>>>>>>
> >>>>>>> No
> >>>>>>>
> >>>>>>>> - If not:
> >>>>>>>>   - what are we doing with plugins that define multiple
> >> <feature>
> >>>>>> tags?
> >>>>>>>
> >>>>>>> We define two <param>s that hold the plugin ID an
version. In
> >> older
> >>>>>>> versions of cordova <feature> was called <plugin>
and the mapping
> >> was
> >>>>>>> one-to-one and it still seems to be the case. If for whatever
> >> reason
> >>>>>>> one needs to have 2+ <feature>s for one plugin, all
<feature> tags
> >>>>>>> should define <param>s that indicate ID/version.
> >>>>>>>
> >>>>>>>>   - what are we doing if apps directly define <feature>
tags
> >>>>> directly
> >>>>>> in
> >>>>>>>> their config.xml (outside of plugins)? This is still
common for
> >>>>> plugins
> >>>>>>>> that haven't been updated to plugman. I think we do
this for
> >>>> plugins
> >>>>>>>> bundled with the platforms (e.g. Android's App plugin)
> >>>>>>>
> >>>>>>> I am not sure I understand the question but everything gets
> >> defined
> >>>> in
> >>>>>>> the top-level config.xml (plugins, js-only plugins and
> >>>>>>> platform-specific things like Android's App plugin).
> >>>>>> I just wanted to point out that people still copy & paste
in
> >> <feature>
> >>>>> tags
> >>>>>> directly into their config.xml for plugins that haven't been
> >>>>> plugmanified.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cons:
> >>>>>>>>> - Harder to implement for us. "Should still take
less time than
> >>>>>>>>> arguing on the topic" said Braden ;-)
> >>>>>>>>> - Previous Cordova platforms might or might not
choke when they
> >>>> see
> >>>>>>>>> JS-only plugins listed as <feature>s but it's
unlikely.
> >>>>>>>> Android chokes:
> >>
> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/PluginManager.java
> >>>>>>>
> >>>>>>> Can you be specifc ? From what I read from PluginManager.java
and
> >>>>>>> PluginEntry.java is that it gets added to a HashMap but
the class
> >>>> only
> >>>>>>> gets instantiated if "onload" <param> is defined or
if
> >> getPlugin() is
> >>>>>>> called when JS is called but exec not called for JS-only
plugins
> >>>>>>> right?
> >>>>>> Sorry, should have just tried it out before speaking up. I thought
> >>>>> adding a
> >>>>>> null key would be a problem, but it seems as though hash maps
do
> >> allow
> >>>>>> them.
> >>>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Not sure if this was considered, but instead of using
a config
> >>>> file,
> >>>>> we
> >>>>>>>> could generate a source file that gets compiled in.
Would
> >> eliminate
> >>>>> any
> >>>>>>>> performance concerns and stay out of files that users
might be
> >>>>> peering
> >>>>>>> at.
> >>>>>>>
> >>>>>>> Sure but this would only solve the app-harness problem we
could
> >> also
> >>>>>>> solve at least two more problems:
> >>>>>>> - Have one canonical config.xml which is a path to making
> >> platforms
> >>>>>>> true build artifacts.
> >>>>>>> - Have the ability install all plugins all at once (ala
npm
> >> install).
> >>>>>> Good points. generating a source file == bad idea.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
> >>>>>>>>> <braden@chromium.org> wrote:
> >>>>>>>>>> Following up on my big config-and-metadata summary
in the
> >> other
> >>>>>>> thread,
> >>>>>>>>> the
> >>>>>>>>>> file in question here is the platform config.xml
(that is,
> >>>>>>>>>> $PROJECT/platforms/<platform>/.../config.xml,
see my
> >> summary).
> >>>>>>>>>> Significantly, this file is written by Plugman
and CLI, and
> >> read
> >>>>> by
> >>>>>>> the
> >>>>>>>>>> native platform. The user never reads or writes
this file
> >>>> directly
> >>>>>> in
> >>>>>>> the
> >>>>>>>>>> normal flow of things.
> >>>>>>>>>>
> >>>>>>>>>> Braden
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson
<
> >>>>>>> braden@chromium.org
> >>>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> There's a bit of a BC issue here because
cordova.js needs to
> >>>> know
> >>>>>>> what
> >>>>>>>>>>> file to inject a <script> tag for,
so it can load the file
> >> and
> >>>>> then
> >>>>>>> load
> >>>>>>>>>>> its module. That's why I hesitated to modify
the format of
> >> that
> >>>>>> file,
> >>>>>>>>>>> originally. (It currently sets module.exports
to an array of
> >>>>>>> <js-module>
> >>>>>>>>>>> info.) Like Andrew says, entirely possible
to make the
> >> change,
> >>>>> just
> >>>>>>> that
> >>>>>>>>>>> some care is required.
> >>>>>>>>>>>
> >>>>>>>>>>> Braden
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Nov 14, 2013 at 3:09 PM, Jonathan
Bond-Caron <
> >>>>>>>>>>> jbondc@gdesolutions.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>> On Thu Nov 14 01:44 PM, Andrew Grieve
wrote:
> >>>>>>>>>>>>> I'm going to attempt to summarize
in point form:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Goal:
> >>>>>>>>>>>>> - Make available the list of installed
plugins and their
> >>>>>>> versions to
> >>>>>>>>>>>> native side & JS
> >>>>>>>>>>>>> side.
> >>>>>>>>>>>>> - Needed by App Harness to know
whether an app is
> >>>> compatible
> >>>>>> with
> >>>>>>>>> its
> >>>>>>>>>>>>> bundled set of plugins.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Using cordova_plugins.js:
> >>>>>>>>>>>>> - It doesn't have the information
that we need
> >>>>>>>>>>>>> - We could add the extra information,
but not easily
> >> since
> >>>>> the
> >>>>>>> file
> >>>>>>>>>>>> exports an
> >>>>>>>>>>>>> array instead of an object.
> >>>>>>>>>>>>> - This file is not currently parsed
by the native
> >> layer, so
> >>>>>>> having
> >>>>>>>>> the
> >>>>>>>>>>>> info here
> >>>>>>>>>>>>> would be an extra IO on start-up.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Great summary :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is it difficult to rename ' cordova_plugins.js'
to
> >> something
> >>>>> more
> >>>>>>> broad
> >>>>>>>>>>>> 'cordova_meta.js', ' cordova_loader.js',
'cordova_boot.js'
> >> and
> >>>>>>> using an
> >>>>>>>>>>>> object?
> >>>>>>>>>>>> Since it's generated code, first impression
is there's no
> >> BC
> >>>>> issue
> >>>>>>>>> other
> >>>>>>>>>>>> than doing another prepare.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Doesn't seem like there's a way to avoid
the extra IO on
> >> the
> >>>>>> native
> >>>>>>>>> side
> >>>>>>>>>>>> (e.g. cordova_meta.js). If the detailed
list of installed
> >>>>> plugins
> >>>>>>> is in
> >>>>>>>>>>>> xml, how will the JS side access it?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Broader problem is there's no single
cordova meta file
> >> that's
> >>>>>> shared
> >>>>>>>>>>>> between native & js. Considering
that on some platforms,
> >>>> there's
> >>>>>>> only
> >>>>>>>>>>>> JavaScript, putting the information
in JSON seems like a
> >> good
> >>>>>> move.
> >>>
> >>>
> >>>
> >>> --
> >>> Carlos Santana
> >>> <csantana23@gmail.com>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message