iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Shazron <sh...@gmail.com>]

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.

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Michal Mocny <mm...@chromium.org>]

Alright, +1 to creating a cordova-plugins repo as an alternative to new
repos for every possible plugin (plugman and registry have for a while
supported git subdirectories so we don't need repo isolation).  However, I
would also be fine with just using cordova-labs plugin branch, especially
once plugin registry has pointers to repo location based on metadata, so it
really does not matter where they live.

I would also +1 a generic preferences plugin over something ios-specific,
though the other two really do seem better to be ios specific (although
there may be an android-keyboard plugin at some point, developers may not
necessarily want to use both).

-Michal


On Fri, Oct 18, 2013 at 1:59 PM, Jesse <pu...@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 <dr...@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 <mm...@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 <sh...@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 <sh...@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.
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Shazron <sh...@gmail.com>]

The reason it's those plugins is, correct me if I'm wrong, but it is
implied we are supporting those. Months and months ago we already
encouraged[1] plugin authors to move out their plugins to their own repos
from phonegap-plugins because of:
* issue tracking
* user contributions (pull requests)

It was becoming untenable to moderate everything in phonegap-plugins,
because the issue tracker there is a catch-all. With cordova-plugins, it
would be limited (I hope) to odd 'core' plugins that may only support one
platform.


[1]
http://shazronatadobe.wordpress.com/2012/11/07/cordova-plugins-put-them-in-your-own-repo-2/


On Fri, Oct 18, 2013 at 1:31 PM, Anis KADRI <an...@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 <sh...@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 <mm...@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 <sh...@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 <pu...@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 <dr...@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 <
> mmocny@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 <sh...@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 <sh...@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.
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[James Jong <wj...@gmail.com>]

Shaz, thanks for the work not this!
-James Jong

On Nov 4, 2013, at 4:06 PM, Shazron <sh...@gmail.com> wrote:

> cordova-plugins repo created
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;a=summary
> 
> I'll start migrating by EOD cordova-labs/#plugins
> 
> 
> On Mon, Oct 21, 2013 at 9:13 AM, Shazron <sh...@gmail.com> wrote:
> 
>> INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902
>> 
>> 
>> On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
>> 
>>> Discreet repos do have value for discreet issue tracking IMO even when you
>>> use Jira. For example, feature branching is easier to reason about.
>>> 
>>> /me shrugs
>>> 
>>> One big repo to rule them all has created more problems than perceived
>>> benifits in our past experience so maybe I'm just allergic.
>>> 
>>> On Saturday, October 19, 2013, Michal Mocny wrote:
>>> 
>>>> Anis, when we were first ripping out the plugins getting ready for 3.0
>>> we
>>>> didn't yet have support for plugins in git repo subdirs.  I think we had
>>>> that functionality by 3.0 launch but by then we have created a bunch of
>>>> repos and momentum followed through.  We *could* merge them all into a
>>>> cordova-plugins repo, but I'm not sure that has value.  We *could*
>>> graduate
>>>> plugins out of cordova-plugins into discrete repos, but I'm not sure
>>> that
>>>> has value either.  For end users, and for us devs, it really doesn't
>>>> matter, so we should do whats most comfortable.
>>>> 
>>>> Brian, at the moment we aren't using github for issue tracking anyway,
>>> so
>>>> "discrete issue tracking" doesn't need to mean "discrete git repo".
>>> Likely
>>>> we do want to create a JIRA component for "graduated" plugins.  The only
>>>> benefit to moving to discrete repos I can think of is consistency, which
>>>> may very well have value (esp for tooling support like coho).
>>>> 
>>>> -Michal
>>>> 
>>>> 
>>>> On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b...@brian.io> wrote:
>>>> 
>>>>> 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 <an...@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 <sh...@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 <
>>> mmocny@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 <sh...@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 <
>>> purplecabbage@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
>>>>>> i
>>> 
>> 
>> 

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Michal Mocny <mm...@chromium.org>]

woo-hoo finally!


On Mon, Nov 4, 2013 at 4:06 PM, Shazron <sh...@gmail.com> wrote:

> cordova-plugins repo created
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;a=summary
>
> I'll start migrating by EOD cordova-labs/#plugins
>
>
> On Mon, Oct 21, 2013 at 9:13 AM, Shazron <sh...@gmail.com> wrote:
>
> > INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902
> >
> >
> > On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> Discreet repos do have value for discreet issue tracking IMO even when
> you
> >> use Jira. For example, feature branching is easier to reason about.
> >>
> >>  /me shrugs
> >>
> >> One big repo to rule them all has created more problems than perceived
> >> benifits in our past experience so maybe I'm just allergic.
> >>
> >> On Saturday, October 19, 2013, Michal Mocny wrote:
> >>
> >> > Anis, when we were first ripping out the plugins getting ready for 3.0
> >> we
> >> > didn't yet have support for plugins in git repo subdirs.  I think we
> had
> >> > that functionality by 3.0 launch but by then we have created a bunch
> of
> >> > repos and momentum followed through.  We *could* merge them all into a
> >> > cordova-plugins repo, but I'm not sure that has value.  We *could*
> >> graduate
> >> > plugins out of cordova-plugins into discrete repos, but I'm not sure
> >> that
> >> > has value either.  For end users, and for us devs, it really doesn't
> >> > matter, so we should do whats most comfortable.
> >> >
> >> > Brian, at the moment we aren't using github for issue tracking anyway,
> >> so
> >> > "discrete issue tracking" doesn't need to mean "discrete git repo".
> >>  Likely
> >> > we do want to create a JIRA component for "graduated" plugins.  The
> only
> >> > benefit to moving to discrete repos I can think of is consistency,
> which
> >> > may very well have value (esp for tooling support like coho).
> >> >
> >> > -Michal
> >> >
> >> >
> >> > On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b...@brian.io> wrote:
> >> >
> >> > > 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 <an...@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 <sh...@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 <
> >> mmocny@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 <sh...@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 <
> >> purplecabbage@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
> >> > > > i
> >>
> >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Shazron <sh...@gmail.com>]

cordova-plugins repo created
https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;a=summary

I'll start migrating by EOD cordova-labs/#plugins


On Mon, Oct 21, 2013 at 9:13 AM, Shazron <sh...@gmail.com> wrote:

> INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902
>
>
> On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> Discreet repos do have value for discreet issue tracking IMO even when you
>> use Jira. For example, feature branching is easier to reason about.
>>
>>  /me shrugs
>>
>> One big repo to rule them all has created more problems than perceived
>> benifits in our past experience so maybe I'm just allergic.
>>
>> On Saturday, October 19, 2013, Michal Mocny wrote:
>>
>> > Anis, when we were first ripping out the plugins getting ready for 3.0
>> we
>> > didn't yet have support for plugins in git repo subdirs.  I think we had
>> > that functionality by 3.0 launch but by then we have created a bunch of
>> > repos and momentum followed through.  We *could* merge them all into a
>> > cordova-plugins repo, but I'm not sure that has value.  We *could*
>> graduate
>> > plugins out of cordova-plugins into discrete repos, but I'm not sure
>> that
>> > has value either.  For end users, and for us devs, it really doesn't
>> > matter, so we should do whats most comfortable.
>> >
>> > Brian, at the moment we aren't using github for issue tracking anyway,
>> so
>> > "discrete issue tracking" doesn't need to mean "discrete git repo".
>>  Likely
>> > we do want to create a JIRA component for "graduated" plugins.  The only
>> > benefit to moving to discrete repos I can think of is consistency, which
>> > may very well have value (esp for tooling support like coho).
>> >
>> > -Michal
>> >
>> >
>> > On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> > > 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 <an...@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 <sh...@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 <
>> mmocny@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 <sh...@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 <
>> purplecabbage@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
>> > > > i
>>
>
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Shazron <sh...@gmail.com>]

INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902


On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux <b...@brian.io> wrote:

> Discreet repos do have value for discreet issue tracking IMO even when you
> use Jira. For example, feature branching is easier to reason about.
>
>  /me shrugs
>
> One big repo to rule them all has created more problems than perceived
> benifits in our past experience so maybe I'm just allergic.
>
> On Saturday, October 19, 2013, Michal Mocny wrote:
>
> > Anis, when we were first ripping out the plugins getting ready for 3.0 we
> > didn't yet have support for plugins in git repo subdirs.  I think we had
> > that functionality by 3.0 launch but by then we have created a bunch of
> > repos and momentum followed through.  We *could* merge them all into a
> > cordova-plugins repo, but I'm not sure that has value.  We *could*
> graduate
> > plugins out of cordova-plugins into discrete repos, but I'm not sure that
> > has value either.  For end users, and for us devs, it really doesn't
> > matter, so we should do whats most comfortable.
> >
> > Brian, at the moment we aren't using github for issue tracking anyway, so
> > "discrete issue tracking" doesn't need to mean "discrete git repo".
>  Likely
> > we do want to create a JIRA component for "graduated" plugins.  The only
> > benefit to moving to discrete repos I can think of is consistency, which
> > may very well have value (esp for tooling support like coho).
> >
> > -Michal
> >
> >
> > On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > 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 <an...@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 <sh...@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 <
> mmocny@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 <sh...@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 <
> purplecabbage@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
> > > > i
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Brian LeRoux <b...@brian.io>]

Discreet repos do have value for discreet issue tracking IMO even when you
use Jira. For example, feature branching is easier to reason about.

 /me shrugs

One big repo to rule them all has created more problems than perceived
benifits in our past experience so maybe I'm just allergic.

On Saturday, October 19, 2013, Michal Mocny wrote:

> Anis, when we were first ripping out the plugins getting ready for 3.0 we
> didn't yet have support for plugins in git repo subdirs.  I think we had
> that functionality by 3.0 launch but by then we have created a bunch of
> repos and momentum followed through.  We *could* merge them all into a
> cordova-plugins repo, but I'm not sure that has value.  We *could* graduate
> plugins out of cordova-plugins into discrete repos, but I'm not sure that
> has value either.  For end users, and for us devs, it really doesn't
> matter, so we should do whats most comfortable.
>
> Brian, at the moment we aren't using github for issue tracking anyway, so
> "discrete issue tracking" doesn't need to mean "discrete git repo".  Likely
> we do want to create a JIRA component for "graduated" plugins.  The only
> benefit to moving to discrete repos I can think of is consistency, which
> may very well have value (esp for tooling support like coho).
>
> -Michal
>
>
> On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > 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 <an...@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 <sh...@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 <mm...@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 <sh...@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 <pu...@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
> > > i

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Michal Mocny <mm...@chromium.org>]

Anis, when we were first ripping out the plugins getting ready for 3.0 we
didn't yet have support for plugins in git repo subdirs.  I think we had
that functionality by 3.0 launch but by then we have created a bunch of
repos and momentum followed through.  We *could* merge them all into a
cordova-plugins repo, but I'm not sure that has value.  We *could* graduate
plugins out of cordova-plugins into discrete repos, but I'm not sure that
has value either.  For end users, and for us devs, it really doesn't
matter, so we should do whats most comfortable.

Brian, at the moment we aren't using github for issue tracking anyway, so
"discrete issue tracking" doesn't need to mean "discrete git repo".  Likely
we do want to create a JIRA component for "graduated" plugins.  The only
benefit to moving to discrete repos I can think of is consistency, which
may very well have value (esp for tooling support like coho).

-Michal


On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux <b...@brian.io> wrote:

> 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 <an...@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 <sh...@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 <mm...@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 <sh...@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 <pu...@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 <dr...@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 <
> > mmocny@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 <sh...@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 <shazron@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.
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Brian LeRoux <b...@brian.io>]

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 <an...@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 <sh...@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 <mm...@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 <sh...@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 <pu...@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 <dr...@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 <
> mmocny@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 <sh...@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 <sh...@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.
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Anis KADRI <an...@gmail.com>]

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 <sh...@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 <mm...@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 <sh...@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 <pu...@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 <dr...@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 <mm...@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 <sh...@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 <sh...@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.
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Shazron <sh...@gmail.com>]

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 <mm...@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 <sh...@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 <pu...@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 <dr...@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 <mm...@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 <sh...@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 <sh...@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.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Michal Mocny <mm...@chromium.org>]

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 <sh...@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 <pu...@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 <dr...@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 <mm...@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 <sh...@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 <sh...@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.
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Shazron <sh...@gmail.com>]

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 <pu...@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 <dr...@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 <mm...@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 <sh...@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 <sh...@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.
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Jesse <pu...@gmail.com>]

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 <dr...@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 <mm...@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 <sh...@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 <sh...@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.
> > > >
> > > >
> > >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[David Kemp <dr...@google.com>]

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 <mm...@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 <sh...@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 <sh...@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.
> > >
> > >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Michal Mocny <mm...@chromium.org>]

+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 <sh...@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 <sh...@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.
> >
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Shazron <sh...@gmail.com>]

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 <sh...@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.
>
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Steven Gill <st...@gmail.com>]

+1

Lets start a new thread about what some of these new meta tags should be


On Thu, Oct 17, 2013 at 4:17 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Awesome! +1 on all the things!
>
>
> On Thu, Oct 17, 2013 at 7:11 PM, Shazron <sh...@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.
> >
>

Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo

[Andrew Grieve <ag...@chromium.org>]

Awesome! +1 on all the things!


On Thu, Oct 17, 2013 at 7:11 PM, Shazron <sh...@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.
>