cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: <plugins> tag, and accessing the plugin list
Date Fri, 15 Nov 2013 16:50:54 GMT
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.
> > > >> >>>
> > > >> >>>
> > > >> >>
> > > >>
> > >
> >
>

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