cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 22:55:21 GMT
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 <fil@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message