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