cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 23:04:43 GMT
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
View raw message