Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D1A9210DC4 for ; Fri, 15 Nov 2013 16:52:30 +0000 (UTC) Received: (qmail 89536 invoked by uid 500); 15 Nov 2013 16:52:30 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 89510 invoked by uid 500); 15 Nov 2013 16:52:30 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 89502 invoked by uid 99); 15 Nov 2013 16:52:29 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Nov 2013 16:52:29 +0000 X-ASF-Spam-Status: No, hits=1.7 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of csantana23@gmail.com designates 74.125.82.50 as permitted sender) Received: from [74.125.82.50] (HELO mail-wg0-f50.google.com) (74.125.82.50) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Nov 2013 16:52:22 +0000 Received: by mail-wg0-f50.google.com with SMTP id k14so3767971wgh.17 for ; Fri, 15 Nov 2013 08:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4Cf/QbIvHrCWKnfKI5P5pgpz/rdN3g+kz4m1C2Xe5cQ=; b=Bww1y9c086QjkrwfgdmgzMtgzm249QQuRefuN7gz+qz0mGRMnD3oarVnn1SFFZwSKV kiAvlYVMRIMwyypK1LSEmROM+ZZ3DxoLgiaajhOlWYmvkY+Lww9ruC0r269y36M3ogYW nse9N6yLNfYpmH5nUY2fnuPumYJJBTBRCvxJYZSaUXYlMOd93XbLgC6O0rcfgWlVZX0U cQ8G/Zs3L6K2p5lxlU9Jt1/GpkrkbJtr0m4akB9Kh9bxHj2uWz6l9tfFyjp0Vabran+D +QrkBNNry30iK5JwLmO66lnP6ltKHHf72hCjcpqtPBBBqH5M8fkvfF1uULqZ2VUF6uEE Bbeg== MIME-Version: 1.0 X-Received: by 10.194.201.225 with SMTP id kd1mr7405639wjc.35.1384534322337; Fri, 15 Nov 2013 08:52:02 -0800 (PST) Received: by 10.194.47.243 with HTTP; Fri, 15 Nov 2013 08:52:02 -0800 (PST) In-Reply-To: References: <3fdbf7686b354e35a8ba4120468c63bc@BN1PR07MB135.namprd07.prod.outlook.com> Date: Fri, 15 Nov 2013 11:52:02 -0500 Message-ID: Subject: Re: tag, and accessing the plugin list From: Carlos Santana To: "dev@cordova.apache.org" Content-Type: multipart/alternative; boundary=047d7b86f172765f4e04eb3a04a7 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b86f172765f4e04eb3a04a7 Content-Type: text/plain; charset=ISO-8859-1 +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 wrote: > That sounds good to me. > > > On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson >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 uses with specialized tags to inject permissions and > > 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 > >wrote: > > > > > I think the thing that irks me about the proposal to fiddle with > > > s, is that right now plugins put them in 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 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 element in your payload: > > > - Plugman will insert two new 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 targets that match the > > > above conditions: > > > - Plugman will add one for you with a default payload of a > > 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 > > > for common things. Seems like it would be simpler for > both > > > plugman and plugin devs to have outside of . 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 > , > > > , plugin iD & version, even 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 > > wrote: > > > > > > > On Thu, Nov 14, 2013 at 7:22 PM, Andrew Grieve > > > > > wrote: > > > > > On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI > > > > wrote: > > > > > > > > > >> So... > > > > >> > > > > >> We just had a good chat about this topic with Braden and Gorkem > and > > we > > > > >> think that adding s to the existing 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 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 to not directly > > define > > > > > bridge mappings? > > > > > > > > No > > > > > > > > > - Is the idea to have a new tag within that defines > the > > > > bridge > > > > > binding? > > > > > > > > No > > > > > > > > > - If not: > > > > > - what are we doing with plugins that define multiple > > > tags? > > > > > > > > We define two s that hold the plugin ID an version. In older > > > > versions of cordova was called and the mapping was > > > > one-to-one and it still seems to be the case. If for whatever reason > > > > one needs to have 2+ s for one plugin, all tags > > > > should define s that indicate ID/version. > > > > > > > > > - what are we doing if apps directly define 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 > > 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 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" 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 > > > > >> 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//.../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 < > > > > braden@chromium.org > > > > >> >wrote: > > > > >> > > > > > >> >> There's a bit of a BC issue here because cordova.js needs to > know > > > > what > > > > >> >> file to inject a