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 87450FB2F for ; Wed, 17 Apr 2013 18:07:49 +0000 (UTC) Received: (qmail 50306 invoked by uid 500); 17 Apr 2013 18:07:49 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 50273 invoked by uid 500); 17 Apr 2013 18:07:49 -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 50264 invoked by uid 99); 17 Apr 2013 18:07:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Apr 2013 18:07:49 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates 64.18.1.29 as permitted sender) Received: from [64.18.1.29] (HELO exprod6og112.obsmtp.com) (64.18.1.29) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Apr 2013 18:07:45 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKUW7k3NaK2bcFOTkgKhf9wldanyITrLHU@postini.com; Wed, 17 Apr 2013 11:07:24 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r3HI4D1v021004 for ; Wed, 17 Apr 2013 11:04:13 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r3HI3BAm006541 for ; Wed, 17 Apr 2013 11:07:23 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Wed, 17 Apr 2013 11:06:16 -0700 From: Filip Maj To: "dev@cordova.apache.org" Date: Wed, 17 Apr 2013 11:06:14 -0700 Subject: Re: plugman + plugin spec final q's Thread-Topic: plugman + plugin spec final q's Thread-Index: Ac47lkBZ6pZwwTT9ScORZX9xmTTEGw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Kay ill update the spec On 4/17/13 11:01 AM, "Braden Shepherdson" wrote: >I think there will be a common repo, where the Cordova core plugins and >some others live. See the spec for the remotes.js file; I think it should >search for plugins with the given name in each of those universes. >Specifying a url in the would then only be necessary for >other >universes. > >Braden > > >On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj wrote: > >> But then we'd need to be able to discover the different universes.. >>Unless >> we all agree on a "default", don't think this is optional.. >> >> On 4/17/13 10:53 AM, "Jeffrey Heifetz" wrote: >> >> >Coming back to Braden's suggestion of specifying a url and id for >>plugin >> >dependency, I think this is the correct route, and would go further to >> >suggest the url is optional. I do not believe we should inherently tie >> >plugin dependency to the exact source. Thats why we have a discovery >> >system and multiple places to get a plugin from. >> > >> >On 13-04-17 1:37 PM, "Filip Maj" wrote: >> > >> >>Braden and I had a little chat on IRC about install/uninstall and >>calling >> >>prepare. We've agreed that having prepare as a separate command is >>useful >> >>(you tweak some plugin JS files, add more JS files, and want that >> >>reflected in your app), but also calling prepare automatically after >>an >> >>install and uninstall makes sense too (otherwise people using plugman >> >>will >> >>have to call prepare manually after calling install or uninstall). >> >> >> >>FTR, --prepare composes the cordova_plugins.json object that is read >>by >> >>cordova.js and handles injecting plugin JS into the app. It will also >>be >> >>responsible for handling permissions that plugins require and setting >>up >> >>platform manifests appropriately based on all installed plugins. >> >> >> >>On 4/17/13 10:25 AM, "Brian LeRoux" wrote: >> >> >> >>>Braden: you thinking that the config is canonical and then prepare >> >>>quietly >> >>>does the right thing based on that? >> >>> >> >>>(Agree less steps is exactly what we're going for here.) >> >>> >> >>> >> >>>On Wed, Apr 17, 2013 at 10:16 AM, Braden Shepherdson >> >>>wrote: >> >>> >> >>>> Re: --install calling --prepare: no. It could, though, I suppose. >> >>>> >> >>>> Why not have --prepare handle the plugins rather than >>install/remove. >> >>>>We're >> >>>> trying to make less, not more, happen at install time. Someday I >>hope >> >>>> --install ceases to exist. >> >>>> >> >>>> >> >>>> On Wed, Apr 17, 2013 at 12:59 PM, Filip Maj wrote: >> >>>> >> >>>> > Max, yeah, at the top of the plugman readme (in both future and >> >>>>master I >> >>>> > believe), the usage docs don't specify --install or --uninstall >>as >> >>>>an >> >>>> > available command, but those commands are referenced right after >>the >> >>>> usage >> >>>> > section. I'd be in favor of using --fetch for the RETRIEVAL of >> >>>>plugins, >> >>>> > --remove for the removal of plugins from the local plugins cache, >> >>>>and >> >>>> > --install and --uninstall for the relevant actions. >> >>>> > >> >>>> > Max, re (2): correct. >> >>>> > >> >>>> > To Braden's points: >> >>>> > >> >>>> > - I'm fine with url + name attributes for elements. >> >>>>Will >> >>>> > update the spec/README shortly. >> >>>> > - Re I will add a note about that to the spec as >>well. >> >>>> > - Re parsing package Ids, fair enough. >> >>>> > - About "namespacing" iOS source files, this sounds like a good >> >>>>idea. >> >>>> > This is something that plugman can handle as well, yes? That is, >> >>>> > management of the plist and pointing to the right location. >> >>>> > - Re config munging and permissions. I vote in favor of removing >> >>>>all >> >>>> > permissions and re-adding all of them with every change in >>plugins >> >>>>(add >> >>>> or >> >>>> > remove), with a de-duping pass. Brute force approach but it'll >>work >> >>>>and >> >>>> is >> >>>> > simple. However spec wise we need a separate element for this ya? >> >>>> > or something? Then based on what tag >>houses >> >>>>a >> >>>> > tag we can deduce where and how to set up the >> >>>>appropriate >> >>>> > native permissions. >> >>>> > - Re the different <*-file> elements. I believe behavior in how >> >>>>header >> >>>> > and source files are handled on iOS are identical, so >>consolidating >> >>>>those >> >>>> > is an easy simplification. I will update the spec with that. I'll >> >>>>leave >> >>>> > resource-file in there for now. >> >>>> > >> >>>> > One more question that came up: does a plugman --install call >> >>>>implicitly >> >>>> > call plugman --prepare ? >> >>>> > >> >>>> > On 4/17/13 9:31 AM, "Max Woghiren" wrote: >> >>>> > >> >>>> > >(1) On line 25 of the cordova-plugman readme, is the command >> >>>>missing >> >>>> (ie. >> >>>> > >--add or --install or whatever)? >> >>>> > > >> >>>> > >(2) Though two versions of a plugin are not allowed, I just >>want to >> >>>>make >> >>>> > >sure: there will be some kind of detection that it's okay if the >> >>>> > >*same*version of a plugin has already been installed by a >>previous >> >>>> > >dependency, >> >>>> > >right? (For example, plugins A and B both depend on C v1.0, so >> >>>>plugman >> >>>> > >will determine that this is okay, whereas if A depends on C v1.0 >> >>>>and >> >>>>B >> >>>> > >depends on C v1.1, there'll be an error). >> >>>> > > >> >>>> > > >> >>>> > >On Wed, Apr 17, 2013 at 3:08 AM, Filip Maj >>wrote: >> >>>> > > >> >>>> > >> Hey all, >> >>>> > >> >> >>>> > >> I've done a review of the spec and updated it. Check it out at >> >>>>the >> >>>> > >>README >> >>>> > >> in the plugman repo's future branch [1]. I've added the last >>bit >> >>>>to >> >>>> it: >> >>>> > >> and elements. Here is an example: >> >>>> > >> >> >>>> > >> >> >>>> > >> > >>>> > >> url=3D"http://plugins.cordova.io/com.facebook.plugin/plugin.xm= l" >> /> >> >>>> > >> > >>>> > >>=20 >>url=3D"http://plugins.phonegap.com/com.adobe.omniture/plugin.xml" >> >>>> > >> version=3D"1.0.0" /> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> Dependencies are specified by providing a url and optionally >>some >> >>>>way >> >>>> of >> >>>> > >> describing what version of the plugin you want. The only >> >>>>constraint >> >>>> > >> imposed on plugin dependencies right now is only a single >>version >> >>>>of a >> >>>> > >> plugin can be installed in an app at the same time. I think >>this >> >>>>is >> >>>> good >> >>>> > >> enough, but wanted to let everyone know and give people time >>to >> >>>> comment. >> >>>> > >> >> >>>> > >> Also did a bunch of updates/tweaks to the plugin.xml spec, >>made >> >>>> explicit >> >>>> > >> some failures (if there are file conflicts, error noisily, >>that >> >>>>kind >> >>>> of >> >>>> > >> stuff). I have a PluginTooling [2] wiki article up where I am >> >>>>doing my >> >>>> > >> best to summarize these various reqs/use cases floating around >> >>>>the >> >>>> list, >> >>>> > >> IRC, hangout discussions regarding plugin tooling >>development. If >> >>>>you >> >>>> > >>have >> >>>> > >> anything to add there please do so! >> >>>> > >> >> >>>> > >> Next, I have a few questions came up when I was going through >>the >> >>>> spec: >> >>>> > >> >> >>>> > >> - does and (specified in the JS symbol >> >>>>mapping >> >>>> > >> section of the plugin spec) create the objects on window if >>they >> >>>>do >> >>>> not >> >>>> > >> exist? I suppose this is more of a cordova.js question than a >> >>>>spec >> >>>> > >> question, but that behavior should be explicit in the spec. >> >>>> > >> - native code elements have a `target` >>attribute >> >>>>where >> >>>> > >>you >> >>>> > >> specify where within the native project the native code >>should be >> >>>> copied >> >>>> > >> into. Is this necessary? For Java files, we could look at the >> >>>>package >> >>>> > >> declaration at the top to determine where to put it. If I'm >>not >> >>>> > >>mistaken, >> >>>> > >> on iOS it doesn't matter where within the directory structure >>of >> >>>>a >> >>>> > >> cordova-ios project you put native code in. What is the >>situation >> >>>>for >> >>>> > >>the >> >>>> > >> Windows (Phone) platforms, and for cordova-osx? >> >>>> > >> - the spec currently only accounts for appending XML to >>specific >> >>>> parts >> >>>> > >>of >> >>>> > >> XML-based configuration documents. Does anyone foresee an >> >>>>instance >> >>>> where >> >>>> > >> some manner of native or cordova-specific config munging OTHER >> >>>>than >> >>>> > >> appending would be necessary? Removal/modification of existing >> >>>> elements? >> >>>> > >> - iOS specific: Do we need separate elements for >>, >> >>>> > >> and ? Can we consolidate into >>one? >> >>>>The >> >>>> > >> current draft of the spec mentions that this may be an >> >>>>implementation >> >>>> > >> detail. >> >>>> > >> >> >>>> > >> Finally, I have two questions/concerns about the command line >> >>>> interface >> >>>> > >> for plugman. >> >>>> > >> >> >>>> > >> 1. The --fetch operation seems to need a redundant --plugin >>flag, >> >>>>e.g. >> >>>> > >> plugman --fetch --plugin . Shouldn't we just axe >>--plugin in >> >>>>this >> >>>> > >> case? >> >>>> > >> 2. The API readme mentions --install and --uninstall flags but >> >>>>the >> >>>> docs >> >>>> > >> only show --fetch and --remove. Can we clarify this? >> >>>> > >> >> >>>> > >> Thanks for everyone's input. I feel we're getting closer to >> >>>>shipping >> >>>> > >>this >> >>>> > >> thing! >> >>>> > >> >> >>>> > >> [1] >> >>>> > >> >> >>>> > >> >> >>>> >> >>>> >> https://git-wip-us.apache.org/repos/asf?p=3Dcordova-plugman.git;a=3Dshor= tlo >> >>>>g >> >>>> > ; >> >>>> > >>h=3D >> >>>> > >> refs/heads/future >> >>>> > >> [2] http://wiki.apache.org/cordova/PluginTooling >> >>>> > >> >> >>>> > >> >> >>>> > >> >>>> > >> >>>> >> >> >> > >> > >> >--------------------------------------------------------------------- >> >This transmission (including any attachments) may contain confidential >> >information, privileged material (including material protected by the >> >solicitor-client or other applicable privileges), or constitute >> >non-public information. Any use of this information by anyone other >>than >> >the intended recipient is prohibited. If you have received this >> >transmission in error, please immediately reply to the sender and >>delete >> >this information from your system. Use, dissemination, distribution, or >> >reproduction of this transmission by unintended recipients is not >> >authorized and may be unlawful. >> >>