Good call, sound rule of thumb On 4/17/13 12:03 PM, "Jesse" <purplecabb...@gmail.com> wrote:
>RE: the permission element >Looks good for wp7 + wp8 >I assume if some platform requires extra data in the permission tag it can >have it, the same way that the blackberry version has the system >attribute. > >@purplecabbage >risingj.com > > >On Wed, Apr 17, 2013 at 11:48 AM, Jeffrey Heifetz ><jheif...@blackberry.com>wrote: > >> Makes sense to me. >> >> Sent from my BlackBerry 10 smartphone on the Rogers network. >> From: Filip Maj >> Sent: Wednesday, April 17, 2013 2:43 PM >> To: dev@cordova.apache.org >> Reply To: dev@cordova.apache.org >> Subject: Re: plugman + plugin spec final q's >> >> >> K one more update: <permission> element that will be a child of >><platform> >> elements. >> >> Examples: >> <platform name="android"> >> <permission name="android.permission.INTERNET" /> >> </platform> >> <platform name="blackberry"> >> <permission name="_sys_use_consumer_push" system="true" /> >> </platform> >> <platform name="wp7"> >> <permission name="ID_CAP_CONTACTS" /> >> </platform> >> >> >> `name` attribute is mandatory, mapping to native strings representing >> specific features/permissions. >> >> `system` attribute is optional and false by default. Only used by >> BlackBerry for certain system-level permissions. >> >> I think this satisfies our use cases. >> >> Thoughts/comments welcome. >> >> >> >> On 4/17/13 11:07 AM, "Jeffrey Heifetz" <jheif...@blackberry.com> wrote: >> >> >I was thinking exactly along the same lines as Braden. Whatever >>universe >> >the cordova core plugins live in will likely be default, with the wild >> >west following it. SO long as plugman is explicit about where it is >> >fetching from, a dev shouldn't have to find the URL and hope it never >> >changes. >> > >> >On 13-04-17 2:01 PM, "Braden Shepherdson" <bra...@chromium.org> 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 <dependency> would then only be necessary for >> >>other >> >>universes. >> >> >> >>Braden >> >> >> >> >> >>On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj <f...@adobe.com> 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" <jheif...@blackberry.com> >> 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" <f...@adobe.com> 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" <b...@brian.io> 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 >> >>> >>><bra...@chromium.org>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 <f...@adobe.com> >> 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 <dependency> >> >>>elements. >> >>> >>>>Will >> >>> >>>> > update the spec/README shortly. >> >>> >>>> > - Re <clobbers> 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? >> >>> >>>> > <permission> or something? Then based on what <platform> tag >> >>>houses >> >>> >>>>a >> >>> >>>> > <permissions> 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" <m...@chromium.org> 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 <f...@adobe.com> >> >>>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: >> >>> >>>> > >> <dependencies> and <dependency> elements. Here is an >>example: >> >>> >>>> > >> >> >>> >>>> > >> <dependencies> >> >>> >>>> > >> <dependency >> >>> >>>> > >> >> >>>url="http://plugins.cordova.io/com.facebook.plugin/plugin.xml"; >> >>> /> >> >>> >>>> > >> <dependency >> >>> >>>> > >> >> >>>url="http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"; >> >>> >>>> > >> version="1.0.0" /> >> >>> >>>> > >> </dependencies> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> > >> 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 <clobbers> and <merges> (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 <source-file> 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 >> >>><source-file>, >> >>> >>>> > >> <resource-file> and <header-file>? 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 <url>. 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=cordova-plugman.git;a=shortlo >> >>> >>>>g >> >>> >>>> > ; >> >>> >>>> > >>h= >> >>> >>>> > >> 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. >> >>> >> >>> >> > >> > >> >--------------------------------------------------------------------- >> >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. >> >> >> --------------------------------------------------------------------- >> 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. >>
