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 29B411077A for ; Fri, 15 Nov 2013 20:49:17 +0000 (UTC) Received: (qmail 5479 invoked by uid 500); 15 Nov 2013 20:49:16 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 5458 invoked by uid 500); 15 Nov 2013 20:49:16 -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 5450 invoked by uid 99); 15 Nov 2013 20:49:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Nov 2013 20:49:16 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com designates 209.85.212.181 as permitted sender) Received: from [209.85.212.181] (HELO mail-wi0-f181.google.com) (209.85.212.181) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Nov 2013 20:49:12 +0000 Received: by mail-wi0-f181.google.com with SMTP id f4so1565324wiw.2 for ; Fri, 15 Nov 2013 12:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=YNb3wN9ydXogIewF7V3EtWM2ODlI1iZugQYunUMAdFA=; b=yGgSUPfV1NYmo/2A+FI3jrAC78+wOXouLYKVXL7OUaFY6IqXiFqbdqtquij7oFKbg6 3AbSiEXCm0hrrMdNMWPHNIYope7lUQVjaOKFxYuZQOYUjLwxEHu+Rctw0L7+bDHU3DTy IwRLPMQF/TfVXQt9wIjtFsmZmqmfJG7qa6MnHqt7Ona0TFBIuG6ORGcAJEMEhg746n8a 0H0hpyKH9/yj7ckKSW8cbgk5wD/q7L5o0HY/L1I+wp7Nk21y8MANKi5I34fuX6eJKjc3 ReeATr/TX1iSD/iovJJJvF81WmEIBU4TiVNaQ1E458G2cLSpy3+pAVLU5Ixw9Qdu+AiH iWQg== MIME-Version: 1.0 X-Received: by 10.180.219.33 with SMTP id pl1mr8746293wic.49.1384548530251; Fri, 15 Nov 2013 12:48:50 -0800 (PST) Sender: brian.leroux@gmail.com Received: by 10.194.61.169 with HTTP; Fri, 15 Nov 2013 12:48:50 -0800 (PST) In-Reply-To: <52866c6e.8e3d320a.0abd.ffffba43@mx.google.com> References: <3fdbf7686b354e35a8ba4120468c63bc@BN1PR07MB135.namprd07.prod.outlook.com> <52866c6e.8e3d320a.0abd.ffffba43@mx.google.com> Date: Fri, 15 Nov 2013 12:48:50 -0800 X-Google-Sender-Auth: vQPoJs67L5ZCQCrhQk3y_Ng_vRs Message-ID: Subject: Re: tag, and accessing the plugin list From: Brian LeRoux To: "dev@cordova.apache.org" Content-Type: multipart/alternative; boundary=001a1134c92851eda804eb3d53a7 X-Virus-Checked: Checked by ClamAV on apache.org --001a1134c92851eda804eb3d53a7 Content-Type: text/plain; charset=ISO-8859-1 Yup that is a sound plan. I think we should continue discussion on the config file thing however. We have clearly accumulated some technical debt here as it is difficult to reason (even describe) the config file dog pile. Given the maturity of Cordova I feel paying off tech debt is crucially important so we can keep adding new features without making everything super brittle. On Fri, Nov 15, 2013 at 10:48 AM, purplecabbage wrote: > +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 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 > wrote: > >> > >> +1 > >> > >> On Fri, Nov 15, 2013 at 8:52 AM, Carlos Santana > >> 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 >>> wrote: > >>> > >>>> That sounds good to me. > >>>> > >>>> > >>>> On Fri, Nov 15, 2013 at 11:29 AM, Braden Shepherdson < > >> braden@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 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 < > agrieve@chromium.org > >>>>>> 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 < > >> agrieve@chromium.org > >>>>> > >>>>>>> wrote: > >>>>>>>> On Thu, Nov 14, 2013 at 5:14 PM, Anis KADRI < > >> anis.kadri@gmail.com> > >>>>>>> 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