cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 23:19:25 GMT
Perfect, lets roll with this for now then.

Next step: write tests for plugman. We're getting closer..

On 4/17/13 4:16 PM, "Jesse" <> 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"
>      <Capability Name="ID_CAP_IDENTITY_DEVICE" />
>      <Capability Name="ID_CAP_IDENTITY_USER" />
>      <Capability Name="ID_CAP_LOCATION" />
>On Wed, Apr 17, 2013 at 4:04 PM, Filip Maj <> wrote:
>> Nope nothing being forced on anyone here. I agree with you: developers
>> should be aware of the platforms they are targeting and should
>> 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
>> device functionality, then wrapping it up in a plugin with a manifest
>> 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
>> Originally my answer was yes, however, Anis brought up good points and
>> 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
>> satisfied with both approaches. However, adding a <permission> element
>> 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
>> 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
>> and our tooling around it.
>> On 4/17/13 3:55 PM, "Jesse" <> wrote:
>> >The use case is any app that has any additional native functionality
>> >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
>> >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
>> >that could exist, but if we can make a few simple changes to allow it,
>> >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
>> >
>> >
>> >
>> >On Wed, Apr 17, 2013 at 3:37 PM, Filip Maj <> 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
>> >> >required by the app itself, and should remain regardless of any
>> >> > This needs to be decided by the app developer themselves imho.
>> >>
>> >> Can you provide one? I don't see how an application's permissions
>> >> stem from the application itself and not the device capabilities the
>> >> 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
>> >> 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.
>> >>
>> >>

View raw message