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. - 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. 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. On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson <bra...@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 > <bra...@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 < >> jbo...@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. >>> >>> >>
