cordova-dev mailing list archives

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