This is a good point. Might be better to warn about unused permissions. (And offer an audit command for cleanup/release purposes.)
On Wed, Apr 17, 2013 at 3:13 PM, Jesse <purplecabb...@gmail.com> wrote: > I think we do have consensus on <permission>, you can ignore the entire > discussion of <requirements> as it is up to the app developer to 'require' > and not the plugin developer. > > 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. > > > > > @purplecabbage > risingj.com > > > On Wed, Apr 17, 2013 at 2:31 PM, Filip Maj <f...@adobe.com> wrote: > > > K I will hold off on <permission> until we come to a consensus. You're > > right in that we could put it in as a child to <config-file>.. > Duplication > > can be easily prevented (check if permission exists already before adding > > it). > > > > Removing config-file stuff during a plugin uninstall is trickier.. If two > > plugins depend on the same permission (or library, or whatever > config-file > > modification), but you only uninstall one of them, we have to make sure > > that it is still there. The naïve first-pass solution to --uninstall > > testPlugin: > > > > 1. Uninstall all the things > > 2. Re-install all the things not named testPlugin > > > > Net result being: testPlugin is uninstalled. > > > > On 4/17/13 2:12 PM, "Anis KADRI" <anis.ka...@gmail.com> wrote: > > > > >On Wed, Apr 17, 2013 at 9:59 AM, Filip Maj <f...@adobe.com> wrote: > > > > > >> Max, yeah, at the top of the plugman readme (in both future and > master I > > >> believe), the usage docs don't specify --install or --uninstall as an > > >> available command, but those commands are referenced right after the > > >>usage > > >> section. I'd be in favor of using --fetch for the RETRIEVAL of > plugins, > > >> --remove for the removal of plugins from the local plugins cache, and > > >> --install and --uninstall for the relevant actions. > > >> > > >> Max, re (2): correct. > > >> > > >> To Braden's points: > > >> > > >> - I'm fine with url + name attributes for <dependency> elements. Will > > >> update the spec/README shortly. > > >> > > > > > >+1 > > > > > > > > >> - Re <clobbers> I will add a note about that to the spec as well. > > >> - Re parsing package Ids, fair enough. > > >> - About "namespacing" iOS source files, this sounds like a good idea. > > >> This is something that plugman can handle as well, yes? That is, > > >> management of the plist and pointing to the right location. > > >> > > > > > >+1. looks like the issue is assigned to me. > > > > > > > > >> - Re config munging and permissions. I vote in favor of removing all > > >> permissions and re-adding all of them with every change in plugins > (add > > >>or > > >> remove), with a de-duping pass. Brute force approach but it'll work > and > > >>is > > >> simple. However spec wise we need a separate element for this ya? > > >> <permission> or something? Then based on what <platform> tag houses a > > >> <permissions> tag we can deduce where and how to set up the > appropriate > > >> native permissions. > > >> > > > > > >I don't think we need a separate element for this. Right now permissions > > >are XML fragments that are added to configuration files and > > >adding/removing > > >works just fine EXCEPT when the XML fragments have variables in them > > >(example PACKAGE_ID, API_KEY etc...). Brett is working on fixing it. > > > > > > > > >> - Re the different <*-file> elements. I believe behavior in how > header > > >> and source files are handled on iOS are identical, so consolidating > > >>those > > >> is an easy simplification. I will update the spec with that. I'll > leave > > >> resource-file in there for now. > > >> > > > > > >As I said on IRC. Header, Source and Resource files are all placed in > > >different sections of the iOS pbxproject so they need to be separated. > > > > > > > > >> > > >> One more question that came up: does a plugman --install call > implicitly > > >> call plugman --prepare ? > > >> > > > > > >It looks like it does now but needs to be tested :-) > > > > > > > > >> > > >> On 4/17/13 9:31 AM, "Max Woghiren" <m...@chromium.org> wrote: > > >> > > >> >(1) On line 25 of the cordova-plugman readme, is the command missing > > >>(ie. > > >> >--add or --install or whatever)? > > >> > > > >> >(2) Though two versions of a plugin are not allowed, I just want to > > >>make > > >> >sure: there will be some kind of detection that it's okay if the > > >> >*same*version of a plugin has already been installed by a previous > > >> >dependency, > > >> >right? (For example, plugins A and B both depend on C v1.0, so > plugman > > >> >will determine that this is okay, whereas if A depends on C v1.0 and > B > > >> >depends on C v1.1, there'll be an error). > > >> > > > >> > > > >> >On Wed, Apr 17, 2013 at 3:08 AM, Filip Maj <f...@adobe.com> wrote: > > >> > > > >> >> Hey all, > > >> >> > > >> >> I've done a review of the spec and updated it. Check it out at the > > >> >>README > > >> >> in the plugman repo's future branch [1]. I've added the last bit to > > >>it: > > >> >> <dependencies> and <dependency> elements. Here is an example: > > >> >> > > >> >> <dependencies> > > >> >> <dependency > > >> >> url="http://plugins.cordova.io/com.facebook.plugin/plugin.xml"; /> > > >> >> <dependency > > >> >> url="http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"; > > >> >> version="1.0.0" /> > > >> >> </dependencies> > > >> >> > > >> >> > > >> >> Dependencies are specified by providing a url and optionally some > > >>way of > > >> >> describing what version of the plugin you want. The only constraint > > >> >> imposed on plugin dependencies right now is only a single version > of > > >>a > > >> >> plugin can be installed in an app at the same time. I think this is > > >>good > > >> >> enough, but wanted to let everyone know and give people time to > > >>comment. > > >> >> > > >> >> Also did a bunch of updates/tweaks to the plugin.xml spec, made > > >>explicit > > >> >> some failures (if there are file conflicts, error noisily, that > kind > > >>of > > >> >> stuff). I have a PluginTooling [2] wiki article up where I am doing > > >>my > > >> >> best to summarize these various reqs/use cases floating around the > > >>list, > > >> >> IRC, hangout discussions regarding plugin tooling development. If > you > > >> >>have > > >> >> anything to add there please do so! > > >> >> > > >> >> Next, I have a few questions came up when I was going through the > > >>spec: > > >> >> > > >> >> - does <clobbers> and <merges> (specified in the JS symbol mapping > > >> >> section of the plugin spec) create the objects on window if they do > > >>not > > >> >> exist? I suppose this is more of a cordova.js question than a spec > > >> >> question, but that behavior should be explicit in the spec. > > >> >> - native code <source-file> elements have a `target` attribute > where > > >> >>you > > >> >> specify where within the native project the native code should be > > >>copied > > >> >> into. Is this necessary? For Java files, we could look at the > package > > >> >> declaration at the top to determine where to put it. If I'm not > > >> >>mistaken, > > >> >> on iOS it doesn't matter where within the directory structure of a > > >> >> cordova-ios project you put native code in. What is the situation > for > > >> >>the > > >> >> Windows (Phone) platforms, and for cordova-osx? > > >> >> - the spec currently only accounts for appending XML to specific > > >>parts > > >> >>of > > >> >> XML-based configuration documents. Does anyone foresee an instance > > >>where > > >> >> some manner of native or cordova-specific config munging OTHER than > > >> >> appending would be necessary? Removal/modification of existing > > >>elements? > > >> >> - iOS specific: Do we need separate elements for <source-file>, > > >> >> <resource-file> and <header-file>? Can we consolidate into one? The > > >> >> current draft of the spec mentions that this may be an > implementation > > >> >> detail. > > >> >> > > >> >> Finally, I have two questions/concerns about the command line > > >>interface > > >> >> for plugman. > > >> >> > > >> >> 1. The --fetch operation seems to need a redundant --plugin flag, > > >>e.g. > > >> >> plugman --fetch --plugin <url>. Shouldn't we just axe --plugin in > > >>this > > >> >> case? > > >> >> 2. The API readme mentions --install and --uninstall flags but the > > >>docs > > >> >> only show --fetch and --remove. Can we clarify this? > > >> >> > > >> >> Thanks for everyone's input. I feel we're getting closer to > shipping > > >> >>this > > >> >> thing! > > >> >> > > >> >> [1] > > >> >> > > >> > > >>>> > > https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlo > > >>>>g > > >> ; > > >> >>h= > > >> >> refs/heads/future > > >> >> [2] http://wiki.apache.org/cordova/PluginTooling > > >> >> > > >> >> > > >> > > >> > > > > >
