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 15:28:58 GMT
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