I think having a staging area for plugins is a good idea and leaving cordova-labs as a prototyping area. Ideally we graduate plugins out of cordova-plugins if they get any sort of traction at all and require discreet issue tracking.
On Fri, Oct 18, 2013 at 1:31 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > I am just curious. Why do that only for those plugins only and not > every other plugins ? I know phonegap/phonegap-plugins was a bad idea > but since git 1.7 there is [1]. I've never used it but just figured it > might apply to our case. I also think namespacing is a bad idea. > > [1] http://schacon.github.io/git/git-read-tree.html#_sparse_checkout > > On Fri, Oct 18, 2013 at 12:57 PM, Shazron <shaz...@gmail.com> wrote: > > Great -- i *think* we have consensus, but I will wait until Monday to > move > > forward just in case. Here's my updated proposal on what has been > discussed > > today: > > > > 1. Ask INFRA to create a cordova-plugins repo > > 2. Move (with history) the cordova-labs plugins branch to the repo in (1) > > 3. Create a CordovaPreferences plugin in (1) with a generic API (and > > predefined constants) -- iOS to start > > > > > > On Fri, Oct 18, 2013 at 11:46 AM, Michal Mocny <mmo...@chromium.org> > wrote: > > > >> Sure we can debate the exact interface when it comes to it. Could use > >> predefined constants instead of strings to help with > >> typing/discoverability: > >> > >> navigator.cordovaPreferences.setPreference(win, fail, > >> navigator.cordovaPreferences.PREFERENCE-iOS-GapBetweenPages, 0); > >> > >> > >> On Fri, Oct 18, 2013 at 2:17 PM, Shazron <shaz...@gmail.com> wrote: > >> > >> > Not feeling hot about the namespace thing - as Jesse said it might > limit > >> > us. Ok - if we do a cordova-plugins repo it won't be hard to move the > >> > plugins branch to it with a filter-branch option, preserving history > -- > >> > great. > >> > > >> > I think a generic preferences plugin is ok (wouldn't be hard to > convert > >> > the interface anyway for the existing code I have for iOS) with the > usual > >> > problems of user education/documentation for upgrades. Putting in the > >> > preference name itself might be error prone (who's a great speller > >> here?), > >> > but I would amend the pseudo code to actually have a failure/success > >> > callback as well for these situations. > >> > > >> > navigator.cordovaPreferences.setPreference(win, fail, > >> > 'iOS-GapBetweenPages",0); > >> > navigator.cordovaPreferences.getPreference(win, fail, > >> > 'iOS-GapBetweenPages"); > >> > > >> > On Fri, Oct 18, 2013 at 10:59 AM, Jesse <purplecabb...@gmail.com> > wrote: > >> > > >> > > If you namespace it to the platform, and later it makes sense to > >> support > >> > it > >> > > on another device, you will have even more issues. > >> > > I think the best approach mentioned is the cordova-plugins repo > which > >> is > >> > > like the wild-west that is purplecabbage/phonegap-plugins except it > is > >> > > managed by cordova contributors only. > >> > > > >> > > Another alternative is to create a generic 'preferences' plugin > which > >> IS > >> > > supported by all platforms, BUT the actual preferences differ > between > >> > > platforms. > >> > > > >> > > Something like: > >> > > navigator.cordovaPreferences.setPreference('iOS-GapBetweenPages",0); > >> > > > >> > > > >> > > > >> > > @purplecabbage > >> > > risingj.com > >> > > > >> > > > >> > > On Fri, Oct 18, 2013 at 10:45 AM, David Kemp <drk...@google.com> > >> wrote: > >> > > > >> > > > I would hate to see plugins that are currently ios only get put > >> there, > >> > > and > >> > > > then later have another platform supported. That would be ugly. > >> > > > > >> > > > Can we at least insist that any plugin that goes in the ios > platform > >> > > have a > >> > > > name like ios-* (likewise for other platforms) > >> > > > > >> > > > > >> > > > On Fri, Oct 18, 2013 at 1:07 PM, Michal Mocny < > mmo...@chromium.org> > >> > > wrote: > >> > > > > >> > > > > +1 to metadata for repo location. > >> > > > > > >> > > > > However, I'm still not 100% why these plugins should live in the > >> > > platform > >> > > > > repo? Its just an arbitrary container, right? I think the fact > >> > thats > >> > > > its > >> > > > > a plugin is more relevant than the fact that they only support > ios. > >> > If > >> > > > > cordova-labs doesn't feel right, then why not make a single > >> > > > cordova-plugins > >> > > > > repo? I know we used to have a phonegap-plugins repo and we > didn't > >> > > like > >> > > > > that, but thats because it had external contributions and > >> unsupported > >> > > > stale > >> > > > > code. > >> > > > > > >> > > > > It doesn't really matter I guess, but I just don't see the > point of > >> > > > having > >> > > > > seperated out all of the plugins into separate repos and now we > >> shove > >> > > > some > >> > > > > back alongside platforms. > >> > > > > > >> > > > > -Michal > >> > > > > > >> > > > > > >> > > > > On Thu, Oct 17, 2013 at 7:32 PM, Shazron <shaz...@gmail.com> > >> wrote: > >> > > > > > >> > > > > > Also, to avoid any "git entanglements" with trying to keep > >> history > >> > > > > between > >> > > > > > the two repos (it's possible but I'm not at level of git > >> black-belt > >> > > > yet), > >> > > > > > I'm just going to copy the folders in, and add them. > >> > > > > > > >> > > > > > > >> > > > > > On Thu, Oct 17, 2013 at 4:11 PM, Shazron <shaz...@gmail.com> > >> > wrote: > >> > > > > > > >> > > > > > > I propose moving these iOS only plugins to the cordova-ios > >> repo, > >> > > and > >> > > > > > > adding the corresponding components in JIRA (ios-statusbar, > >> > > > > ios-keyboard) > >> > > > > > > for issue tracking. > >> > > > > > > With https://issues.apache.org/jira/browse/CB-5026 - plus > >> these > >> > > two > >> > > > > > > plugins, that would make a total of three plugins in > >> cordova-ios > >> > > > > > (probably > >> > > > > > > in a plugins subfolder) > >> > > > > > > > >> > > > > > > Also, would be great to add the extra meta-data (new tags?) > to > >> > > > > > plugins.xml > >> > > > > > > to show which repo this comes from, where issues are > supposed > >> to > >> > > go. > >> > > > I > >> > > > > > > believe we discussed this in the hangout. > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> >
