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