cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: <plugins> tag, and accessing the plugin list
Date Fri, 15 Nov 2013 04:12:52 GMT
On Thu, Nov 14, 2013 at 10: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.
>
>
> >
>
> - 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
>

I think I'm in this boat too.  I originally thought proposal meant changing
the *platform config* by modifying the finally generated <feature> tag to
add new params, but after re-reading, seems you propose making changes to
the *app config* on plugin install time?


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

-1 to generating a source file.  Besides being brittle to do that for each
platform, the compelling use case here is to warn when installing app into
app harness.  We are only downloading the final generated web assets when
loading apps into app harness, so having a native file specify its expected
list of plugins seems like a bad fit.

Also, the performance of doing I/O only if/when you want to read the list
of installed plugins, which at the moment is going to happen when
installing a new app in app harness, not on every apps' startup, is not at
all a performance problem.

I would not at all mind seeing a new prepare artifact with this info
instead of modifying config.xml (though config.xml seems like the easiest
way).


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