I like this design (we should have had this in the first place) - but am concerned of the breaking nature.
Do we have a specific case of a name conflict that we know of? Another way to do this would be to use naming conventions - similar to a namespace. The recommendation would be to prefix the preference name with the plugin id - though that makes preference names rather long and does not guarantee anything. -Nikhil -----Original Message----- From: Shazron [mailto:[email protected]] Sent: Tuesday, September 1, 2015 4:33 PM To: [email protected] Subject: Re: [DISCUSS] Local plugin configuration > > > So what I'm missing from the plugin spec is the possibility to > describe what preferences are available/required for the plugin to > work. > > It being under <feature> would imply this but I think you are asking about the way currently things are. Yeah right now if preference is not added under the <platform> a user wouldn't know about it. > > All relevant platforms > > will now need to support reading of these new tags, and have a way > > for plugins to access them. This would be a major platform version > > bump > because > > of a new API needed for plugins (which is next for cordova-osx and > > cordova-ios but the other platforms already have their major version > > bumps). We could avoid a major version bump if we could shoehorn > > namespacing the plugin preferences into the current settings [1]. > > Is there already a JS API defined for plugins, that hey should expose? > i.e we could then add the > > /* {object} */ Plugin.getConfiguration(); > > to it. > No there is no API for this currently. > > > > The problem would be, if the new tags are specified in plugin.xml, > > and > you > > didn't have the newer platform installed, the plugin won't be > > configured properly. This could be mitigated by having the required > > platform version specified in an <engine> tag, but this will exclude > > your plugin from > older > > platforms. > > I think the plugins need to be backward compatible, you could add a > fallback information, like <feature> > <param name="splashImage" defaultPreference="SplashScreenImage" > default="cordova.png" /> > </feature> > > and plugman should copy over all params anyways, right? > They still won't be configured properly, since older platforms won't know what to do with these new attributes, and won't save them for plugins to access. The config parser is part of the platform. The plugin however, could read this config.xml themselves of course but we're trying to solve this in a generic way that is easier for plugin authors. Also, I found an issue already filed (by me) essentially already asking for what you want: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-6458&data=01%7c01%7cnikhilkh%40microsoft.com%7c358da174d2c54994660308d2b325da62%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jkto%2fhvkmiVg5UX9j2uzVYlSCroxjLRDahhoYwj%2fY%2b0%3d Perhaps we could continue on that issue, I've tentatively labeled the issue for cordova-ios-5.0.x --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
