On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI <[email protected]> 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 > <[email protected]> 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 <[email protected] > >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 < > >> [email protected]> 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. > >>> > >>> > >> >
