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