On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve <[email protected]> wrote: > 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.
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). > > > > >> >> 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? > > > 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). > > >> >> >> 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. >> >>> >> >>> >> >> >>
