+1 to the short term fix and the deep dive punt Sent from my iPhone
> On Nov 15, 2013, at 10:19 AM, Michal Mocny <mmo...@chromium.org> wrote: > > Hmm, sounds pretty un-intrusive. Ship it! > > We should probably schedule a whole hack-a-thon for figuring out the future > of config files. Maybe at our next face-to-face meetup, or just schedule a > hangout in the new year? > > -Michal > > >> On Fri, Nov 15, 2013 at 12:29 PM, Anis KADRI <anis.ka...@gmail.com> wrote: >> >> +1 >> >> On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana <csantan...@gmail.com> >> wrote: >>> +1 >>> >>> Yep I agree this way users can get list of plugins installed from >>> javascript pretty easy on all platforms from a web resource (i.e. >>> cordova_plugins.js >>> ) >>> >>> >>> On Fri, Nov 15, 2013 at 11:50 AM, Andrew Grieve <agri...@chromium.org >>> wrote: >>> >>>> That sounds good to me. >>>> >>>> >>>> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson < >> bra...@chromium.org >>>>> wrote: >>>> >>>>> Looking back over all of this discussion, we have a growing trend of >>>>> dissatisfaction with the current config file setup. We've talked in >> the >>>>> past about moving to JSON format, Andrew is suggesting above replacing >>>> 99% >>>>> of <config-file> uses with specialized tags to inject permissions and >>>>> <feature>s, my summary in the other thread was pretty disgustingly >>>>> complicated, etc. >>>>> >>>>> I propose three things: >>>>> 1. Punt all discussion of overhauling configuration files to the new >>>> year. >>>>> 2. Drop my proposals above, as well as the summary Anis posted of last >>>>> night's discussion. >>>>> 3. Solve the immediate use-case of AppHarness wanting to know what >>>> plugins >>>>> are installed by injecting that object into a new key attached to the >>>> array >>>>> of JS modules in cordova_plugins.js. >>>>> >>>>> This modifies a file that is already clearly a build artifact and not >>>>> touched by humans. It is fully backward compatible, since the array >> of JS >>>>> modules is unchanged when viewed as an array. And it gets me access >> the >>>>> information I needed in the short term to build the AppHarness >>>>> functionality. >>>>> >>>>> How does that sound? >>>>> >>>>> Braden >>>>> >>>>> >>>>> On Fri, Nov 15, 2013 at 10:28 AM, Andrew Grieve <agri...@chromium.org >>>>>> wrote: >>>>> >>>>>> I think the thing that irks me about the proposal to fiddle with >>>>>> <feature>s, is that right now plugins put them in <config-file> >> tags. >>>>> With >>>>>> these tags: >>>>>> >>>>>> - You can specify any target that's an xml file >>>>>> - You can specify any xpath in the parent attribute >>>>>> - plugman will splice in your XML into the target file >> if-and-only-if >>>>> there >>>>>> wasn't already another plugin that spliced in the exact same chunk >> into >>>>> the >>>>>> exact same place. >>>>>> >>>>>> Now, we're proposing to make this <config-file> rule even more >> complex: >>>>>> - You can specify any target that's an xml file >>>>>> - You can specify any xpath in the parent attribute >>>>>> NEW: >>>>>> - If you specify target="config.xml" AND you specify parent xpath >> that >>>>>> evaluates to the same things as parent="/widget" Then: >>>>>> - For each top-level <feature> element in your payload: >>>>>> - Plugman will insert two new <params> into it with your plugin >>>> ID & >>>>>> version >>>>>> - plugman will splice in your XML into the target file >> if-and-only-if >>>>> there >>>>>> wasn't already another plugin that spliced in the exact same chunk >> into >>>>> the >>>>>> exact same place. >>>>>> NEW: >>>>>> - If your plugin does not have any <config-file> targets that match >> the >>>>>> above conditions: >>>>>> - Plugman will add one for you with a default payload of a >> <feature> >>>>> with >>>>>> params. >>>>>> >>>>>> >>>>>> I haven't run it past any real-world users, but it if it sounds >>>>> complicated >>>>>> to me, then I'd be surprised if it wasn't also confusing to others. >>>>>> >>>>>> Maybe a fallout of this discussion is that it's hurting us to be >> using >>>>>> <config-file> for common things. Seems like it would be simpler for >>>> both >>>>>> plugman and plugin devs to have <feature> outside of <config-file>. >> If >>>>> this >>>>>> were the case, I'd be much more open to the idea of altering them >> when >>>> we >>>>>> spliced them in. >>>>>> >>>>>> Going a step further, Michal suggested in another thread that we >> just >>>>>> include the plugin.xml files directly in apps. The more I think >> about >>>>> this, >>>>>> the more it makes sense to me. Why are we even splicing things into >>>>>> config.xml? Seems like we're doing work to lose information. If we >> just >>>>>> included the plugin.xml files directly, we could read out the >>>> <feature>, >>>>>> <access>, plugin iD & version, even <js-module>s. If we want to keep >>>> all >>>>>> the runtime xml in one file, how about splice in the entire >> plugin.xml >>>>> into >>>>>> config.xml? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Thu, Nov 14, 2013 at 11:19 PM, Anis KADRI <anis.ka...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve < >> agri...@chromium.org >>>>> >>>>>>> wrote: >>>>>>>> On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI < >> anis.ka...@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. >>>>>>> >>>>>>> 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). >>>>>> I just wanted to point out that people still copy & paste in >> <feature> >>>>> tags >>>>>> directly into their config.xml for plugins that haven't been >>>>> plugmanified. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 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? >>>>>> Sorry, should have just tried it out before speaking up. I thought >>>>> adding a >>>>>> null key would be a problem, but it seems as though hash maps do >> allow >>>>>> them. >>>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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). >>>>>> Good points. generating a source file == bad idea. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 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. >>> >>> >>> >>> -- >>> Carlos Santana >>> <csantan...@gmail.com> >>
