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