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 03:22:02 GMT
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.


>

- 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?
   - Is the idea to have a new tag within <feature> that defines the bridge
binding?
- If not:
   - what are we doing with plugins that define multiple <feature> tags?
   - 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)




>
> 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


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.


>
>
> 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