cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: plugman + plugin spec final q's
Date Thu, 18 Apr 2013 14:45:29 GMT
The <android:required="true"> tidbit might make it necessary to special
case permissions.

E.g. the app sets a permission with required=true, then a plugin adds the
permission as well. We go to de-dupe, what happens? We'll need logic to
properly combine the two.

For native code added by the app developer, shouldn't we be insisting that
they try to do so by writing an app-specific plugin?


On Wed, Apr 17, 2013 at 7:28 PM, Filip Maj <fil@adobe.com> wrote:

> After chatting with Anis on IRC I think I understand your point a bit
> better with respect to plugin vs. app permissions.
>
> I believe our move from <plugin> to <feature> in an application's
> config.xml should solve this issue. That is, if the application developer
> explicitly lists out permissions they deem as necessary in their
> application, plugman or other plugin tooling should respect those
> permissions and not remove them.
>
> On 4/17/13 4:16 PM, "Jesse" <purplecabbage@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 <fil@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" <purplecabbage@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 <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