Hmm, this could be an implementation detail for windows phone. Requirement vs permission isn't syntactically different. Could we encapsulate Windows Phone requirements as <permission> elements in plugin.xml, and have tooling be smart enough to parse wp7 + wp8 <platform> <permission> elements and drop them into the Windows Phone manifest as whatever elements they need to be?
On 4/17/13 12:16 PM, "Jesse" <purplecabb...@gmail.com> wrote: >While we are there, we may want to add an optional requirements tag. >Requirements let the app specify what device features it must have, for >example NFC. [1] >Logically this would just fall right under platform, and be optional : > > <platform name="wp8"> > <requirement name="ID_REQ_NFC" /> > </platform> > >Does it make sense for us to group these? >ie. > ><platform> > <permissions> > <permission/> > ... > </permissions> > <requirements> > <requirement/> > ... > </requirements> ></platform> > > > > >[1] >http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/04/17/defining >-your-app-s-requirements-for-a-great-customer-experience.aspx > > > >@purplecabbage >risingj.com > > >On Wed, Apr 17, 2013 at 12:04 PM, Filip Maj <f...@adobe.com> wrote: > >> 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. >> >> >> >>
