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