I could, or it could just be an ignored tag for other platforms. It will sit inside the platform tag anyway. could also just add an optional attrib to the permission tag : <permission type='requirement' name='ID_REQ_NFC' />
The names already do contain enough info to easily parse, ID_CAP_* ID_REQ_* not to mention ID_RESOLUTION_* I am down with whatever. @purplecabbage risingj.com On Wed, Apr 17, 2013 at 12:24 PM, Filip Maj <[email protected]> wrote: > 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" <[email protected]> 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 <[email protected]> wrote: > > > >> Good call, sound rule of thumb > >> > >> On 4/17/13 12:03 PM, "Jesse" <[email protected]> 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 > >> ><[email protected]>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: [email protected] > >> >> Reply To: [email protected] > >> >> 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" <[email protected]> > >>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" <[email protected]> > >>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 <[email protected]> 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" <[email protected]> > >> >> 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" <[email protected]> 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" <[email protected]> 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 > >> >> >>> >>><[email protected]>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 <[email protected]> > >> >> 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" <[email protected]> > >> 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 > >><[email protected]> > >> >> >>>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. > >> >> > >> > >> > >
