Perfect, lets roll with this for now then. Next step: write tests for plugman. We're getting closer..
On 4/17/13 4:16 PM, "Jesse" <purplecabb...@gmail.com> wrote: >Yes, <config-file> element would work fine for wp7+8 as well. >I then see no other need for the <permission> element. > ><config-file target="Properties/WMAppManifest.xml" >parent="/Deployment/App/Capabilities"> > <Capability Name="ID_CAP_IDENTITY_DEVICE" /> > <Capability Name="ID_CAP_IDENTITY_USER" /> > <Capability Name="ID_CAP_LOCATION" /> ></config-file> > >@purplecabbage >risingj.com > > >On Wed, Apr 17, 2013 at 4:04 PM, Filip Maj <f...@adobe.com> wrote: > >> Nope nothing being forced on anyone here. I agree with you: developers >> should be aware of the platforms they are targeting and should >>understand >> how their app works, regardless if its written with a cross-platform >> framework or not. >> >> We are talking about a spec helping standardize the way bits of >> functionality can be exposed to cordova applications. If you have >> something very app-specific, we (cordova) should not mandate that it be >> written as a plugin. If you have a cross-platform plugin to access >>special >> device functionality, then wrapping it up in a plugin with a manifest >>that >> is standardized will help with exposure, discovery and usability of the >> plugin. >> >> Back to the issue at hand, the contention was: do we need a special >> section of the spec listing out platform permissions required by a >>plugin? >> Originally my answer was yes, however, Anis brought up good points and >>now >> I am not as convinced. We already have a section for generic XML munging >> (the <config-file> element) which we can use in this case. The specific >> use case that needed satisfying (installing multiple plugins with >> shared/overlapping config changes, then uninstalling one of them, and >> having the shared/overlapping config changes remain in the config) can >>be >> satisfied with both approaches. However, adding a <permission> element >>is, >> in a sense, redundant, as it doesn't satisfy any other use cases that we >> deem necessary. >> >> If there are other use cases in plugin management that are not >>satisfied, >> but would be by adding a <permission> element, then we should list them >> out in this thread so we can keep pushing development of this plugin >>spec >> and our tooling around it. >> >> On 4/17/13 3:55 PM, "Jesse" <purplecabb...@gmail.com> wrote: >> >> >The use case is any app that has any additional native functionality >>added >> >by the developer. ( every app I have ever written ) >> >Otherwise we force an all or nothing stance with cordova use, Android, >> >iOS, wp7, wp8 all support using cordova as a view in an otherwise >>strictly >> >native app, or adding a native view in an otherwise browser-control >> >(typical cordova) based app. >> >I am not suggesting we make drastic efforts to support every type of >>app >> >that could exist, but if we can make a few simple changes to allow it, >>I >> >think we should. >> >Ideally everyone would write any additions to their app as a plugin >> >according to our spec, but do we need to force it? >> > >> >@purplecabbage >> >risingj.com >> > >> > >> >On Wed, Apr 17, 2013 at 3:37 PM, Filip Maj <f...@adobe.com> wrote: >> > >> >> >> >> >However, I do not think that removing permissions will end well. >> >>Looking >> >> >at the bigger picture, I can think of many cases where a permission >>is >> >> >required by the app itself, and should remain regardless of any >>plugin. >> >> > This needs to be decided by the app developer themselves imho. >> >> >> >> Can you provide one? I don't see how an application's permissions >>would >> >> stem from the application itself and not the device capabilities the >>app >> >> needs to access. >> >> >> >> I think for now leaving the permission stuff as children under >> >> <config-file> is good enough, but tweaking our tooling >>implementation to >> >> be smarter about handling it is the way forward. The idea behind the >> >> <config-file> element is: all of its child elements will be appended >> >>into >> >> specific parts of the native manifests for the platform it is >>specified >> >> under. So, as long as the tooling understands that permissions (and >> >> possibly other areas such as "requirements" in windows phone land) >>are a >> >> shared space between different plugins, we are good. >> >> >> >> >> >>
