You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@apache.org> on 2014/03/05 19:14:09 UTC
[cordova-plugins/statusbar] Publishing as core
statusbar is already published org.apache.cordova.statusbar.
And... Since these plugins are somewhat experimental and we're starting the
process of voting and publishing plugins to dist/, I wonder:
a) Should we change the ID of these plugins to, say
"org.apache.cordova.labs"
b) Should we move these plugins to github and have them not under apache
for now, e.g.: com.shazron.statusbar
c) Should we just add them to the plugin release process.
d) Should we just never publish them to the registry and have people use
them via git url.
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Andrew Grieve <ag...@chromium.org>.
sgtm
On Tue, Mar 11, 2014 at 2:01 PM, Jesse <pu...@gmail.com> wrote:
> Andrew, I agree with all of that, and never suggested that statusbar not be
> a plugin.
>
> Attempting to rescue this thread into something we can do? ...
>
>
>
> Plugins:
> [PROPOSAL]
> org.apache.cordova.labs.keyboard
> - a iOS only keyboard plugin doing some very iOS specific stuff, lives in
> labs
> - there is no change here, so proposal is that it stays the same
>
> [PROPOSAL]
> org.apache.cordova.statusbar
> - a status bar plugin for Android, iOS, and Windows Phone, lives in core,
> maintained by at least Jesse
> - statusbar namespace changes, and it get's own repo possibly
>
> To discuss further ( in their own threads )
> - default plugins, really just one plugin with dependencies
> - expected intrinsic functionality, console.log?
>
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > I like this idea. Achieves all concerns. (Separation thereof, and
> > onboarding ease.)
> >
> >
> > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <csantana23@gmail.com
> > >wrote:
> >
> > > +1 Keep it as a plugin not embed into platform repo
> > >
> > > default plugins ?
> > >
> > > what about binding a set of default plugins with our www template app
> > (the
> > > template app specified what plugins are required)
> > >
> > > meaning associate a set of plugins with a template www app, and not
> > > associate with platform or cli
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <agrieve@chromium.org
> > > >wrote:
> > >
> > > > Plugins allow us to share JS. Rolling statusbar into platforms means
> > > > different JS for all platforms, and make it easier for the APIs to
> > > diverge.
> > > >
> > > > Plugins allow us to share docs, and to have the docs live with the
> > code.
> > > > APIs like Android's "app" plugin don't have very good docs (or maybe
> > they
> > > > are just undiscoverable, or maybe I've just missed where they are).
> But
> > > > having consistency with docs is a big win I think, so having
> statusbar
> > > as a
> > > > plugin means devs can go to its plugin page to find its docs.
> > > >
> > > > I think just having default plugins would achieve the "everyone will
> > > > probably want it" concern. But having it show up in "cordova plugin
> ls"
> > > > will help devs discover that it's there and that they should probably
> > use
> > > > it.
> > > >
> > > >
> > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > > jbondc@gdesolutions.com> wrote:
> > > >
> > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > > More on the concept of rolling into a platform ...
> > > > > > My distinction is that there are some things that every platform
> > > should
> > > > > consider a
> > > > > > baseline of browser functionality, and if the OS SDKs do not
> > provide
> > > it
> > > > > out of the
> > > > > > box, then we should. Some examples of this :
> > > > > >
> > > > > > 1. Local XHR, Windows Phone does not support xhr when trying to
> > > access
> > > > a
> > > > > file://
> > > > > > url, I could have made this a plugin that would only be used on
> WP,
> > > but
> > > > > I think
> > > > > > this functionality should be intrinsic, so now it is.
> > > > >
> > > > > +1
> > > > >
> > > > > > 2. console.log: if you create a brand new iOS cordova project,
> the
> > > > > hello-world app
> > > > > > gives you some boilerplate code to get started. One thing that
> new
> > > > > users may
> > > > > > notice is the use of console.log in index.js, however, they will
> > > never
> > > > > see the
> > > > > > output. Hooking conosle.log output to go to the command-line
> > output
> > > of
> > > > > a run
> > > > > > command, or the output window of visual studio, or xcode is the
> > > minimum
> > > > > > functionality, and I personally think it should be built in. This
> > is
> > > > > probably best
> > > > > > discussed in a new thread, as I know Michal has a different
> > opinion,
> > > > > because of
> > > > > > some weinre edge case, but this is meant to serve more as an
> > example.
> > > > > >
> > > > >
> > > > > Yep agree, distinction here is there's ~ "web dev" flow and "native
> > > dev"
> > > > > flow (using an IDE)
> > > > >
> > > > > Both of those should be core somehow
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > <cs...@gmail.com>
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Jesse <pu...@gmail.com>.
+1 sgtm
@purplecabbage
risingj.com
On Thu, Mar 13, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
> Alright, I'm going to start on this today:
>
> org.apache.cordova.keyboard stays in cordova-plugins but has a new
> namespace: org.apache.cordova.labs.keyboard
> org.apache.cordova.statusbar stays in cordova-plugins *for now* until we
> get a new repo, and keeps its existing namespace
>
>
> On Tue, Mar 11, 2014 at 11:55 AM, Jesse <pu...@gmail.com> wrote:
>
> > oops, yeah Shaz. "statusbar namespace does *not* change"
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Tue, Mar 11, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
> >
> > > The proposal looks good to me. Since the majority of the code for the
> two
> > > plugins have been contributed by me, I will continue to help maintain
> > them.
> > > One thing though -- "statusbar namespace changes" -- I believe you
> wanted
> > > to say "statusbar namespace does *not* change"
> > >
> > >
> > >
> > >
> > > On Tue, Mar 11, 2014 at 11:01 AM, Jesse <pu...@gmail.com>
> wrote:
> > >
> > > > Andrew, I agree with all of that, and never suggested that statusbar
> > not
> > > be
> > > > a plugin.
> > > >
> > > > Attempting to rescue this thread into something we can do? ...
> > > >
> > > >
> > > >
> > > > Plugins:
> > > > [PROPOSAL]
> > > > org.apache.cordova.labs.keyboard
> > > > - a iOS only keyboard plugin doing some very iOS specific stuff,
> lives
> > in
> > > > labs
> > > > - there is no change here, so proposal is that it stays the same
> > > >
> > > > [PROPOSAL]
> > > > org.apache.cordova.statusbar
> > > > - a status bar plugin for Android, iOS, and Windows Phone, lives in
> > core,
> > > > maintained by at least Jesse
> > > > - statusbar namespace changes, and it get's own repo possibly
> > > >
> > > > To discuss further ( in their own threads )
> > > > - default plugins, really just one plugin with dependencies
> > > > - expected intrinsic functionality, console.log?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
> > > >
> > > > > I like this idea. Achieves all concerns. (Separation thereof, and
> > > > > onboarding ease.)
> > > > >
> > > > >
> > > > > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <
> > csantana23@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > +1 Keep it as a plugin not embed into platform repo
> > > > > >
> > > > > > default plugins ?
> > > > > >
> > > > > > what about binding a set of default plugins with our www template
> > app
> > > > > (the
> > > > > > template app specified what plugins are required)
> > > > > >
> > > > > > meaning associate a set of plugins with a template www app, and
> not
> > > > > > associate with platform or cli
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <
> > > agrieve@chromium.org
> > > > > > >wrote:
> > > > > >
> > > > > > > Plugins allow us to share JS. Rolling statusbar into platforms
> > > means
> > > > > > > different JS for all platforms, and make it easier for the APIs
> > to
> > > > > > diverge.
> > > > > > >
> > > > > > > Plugins allow us to share docs, and to have the docs live with
> > the
> > > > > code.
> > > > > > > APIs like Android's "app" plugin don't have very good docs (or
> > > maybe
> > > > > they
> > > > > > > are just undiscoverable, or maybe I've just missed where they
> > are).
> > > > But
> > > > > > > having consistency with docs is a big win I think, so having
> > > > statusbar
> > > > > > as a
> > > > > > > plugin means devs can go to its plugin page to find its docs.
> > > > > > >
> > > > > > > I think just having default plugins would achieve the "everyone
> > > will
> > > > > > > probably want it" concern. But having it show up in "cordova
> > plugin
> > > > ls"
> > > > > > > will help devs discover that it's there and that they should
> > > probably
> > > > > use
> > > > > > > it.
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > > > > > jbondc@gdesolutions.com> wrote:
> > > > > > >
> > > > > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > > > > > More on the concept of rolling into a platform ...
> > > > > > > > > My distinction is that there are some things that every
> > > platform
> > > > > > should
> > > > > > > > consider a
> > > > > > > > > baseline of browser functionality, and if the OS SDKs do
> not
> > > > > provide
> > > > > > it
> > > > > > > > out of the
> > > > > > > > > box, then we should. Some examples of this :
> > > > > > > > >
> > > > > > > > > 1. Local XHR, Windows Phone does not support xhr when
> trying
> > to
> > > > > > access
> > > > > > > a
> > > > > > > > file://
> > > > > > > > > url, I could have made this a plugin that would only be
> used
> > on
> > > > WP,
> > > > > > but
> > > > > > > > I think
> > > > > > > > > this functionality should be intrinsic, so now it is.
> > > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > > 2. console.log: if you create a brand new iOS cordova
> > project,
> > > > the
> > > > > > > > hello-world app
> > > > > > > > > gives you some boilerplate code to get started. One thing
> > that
> > > > new
> > > > > > > > users may
> > > > > > > > > notice is the use of console.log in index.js, however, they
> > > will
> > > > > > never
> > > > > > > > see the
> > > > > > > > > output. Hooking conosle.log output to go to the
> command-line
> > > > > output
> > > > > > of
> > > > > > > > a run
> > > > > > > > > command, or the output window of visual studio, or xcode is
> > the
> > > > > > minimum
> > > > > > > > > functionality, and I personally think it should be built
> in.
> > > This
> > > > > is
> > > > > > > > probably best
> > > > > > > > > discussed in a new thread, as I know Michal has a different
> > > > > opinion,
> > > > > > > > because of
> > > > > > > > > some weinre edge case, but this is meant to serve more as
> an
> > > > > example.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yep agree, distinction here is there's ~ "web dev" flow and
> > > "native
> > > > > > dev"
> > > > > > > > flow (using an IDE)
> > > > > > > >
> > > > > > > > Both of those should be core somehow
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Carlos Santana
> > > > > > <cs...@gmail.com>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Shazron <sh...@gmail.com>.
Had to get infra to re-create the statusbar repo since I mistakenly asked
it to be named "cordova-statusbar" instead of "cordova-plugin-statusbar"
(thus the flurry of statusbar commits again)
On Thu, Mar 13, 2014 at 12:43 PM, Shazron <sh...@gmail.com> wrote:
> cordova-statusbar created, that was fast. I'm migrating the statusbar
> folder to that repo now.
>
>
> On Thu, Mar 13, 2014 at 12:35 PM, Shazron <sh...@gmail.com> wrote:
>
>> https://issues.apache.org/jira/browse/INFRA-7444
>>
>>
>> On Thu, Mar 13, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
>>
>>> Alright, I'm going to start on this today:
>>>
>>> org.apache.cordova.keyboard stays in cordova-plugins but has a new
>>> namespace: org.apache.cordova.labs.keyboard
>>> org.apache.cordova.statusbar stays in cordova-plugins *for now* until we
>>> get a new repo, and keeps its existing namespace
>>>
>>>
>>> On Tue, Mar 11, 2014 at 11:55 AM, Jesse <pu...@gmail.com> wrote:
>>>
>>>> oops, yeah Shaz. "statusbar namespace does *not* change"
>>>>
>>>> @purplecabbage
>>>> risingj.com
>>>>
>>>>
>>>> On Tue, Mar 11, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>> > The proposal looks good to me. Since the majority of the code for the
>>>> two
>>>> > plugins have been contributed by me, I will continue to help maintain
>>>> them.
>>>> > One thing though -- "statusbar namespace changes" -- I believe you
>>>> wanted
>>>> > to say "statusbar namespace does *not* change"
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Tue, Mar 11, 2014 at 11:01 AM, Jesse <pu...@gmail.com>
>>>> wrote:
>>>> >
>>>> > > Andrew, I agree with all of that, and never suggested that
>>>> statusbar not
>>>> > be
>>>> > > a plugin.
>>>> > >
>>>> > > Attempting to rescue this thread into something we can do? ...
>>>> > >
>>>> > >
>>>> > >
>>>> > > Plugins:
>>>> > > [PROPOSAL]
>>>> > > org.apache.cordova.labs.keyboard
>>>> > > - a iOS only keyboard plugin doing some very iOS specific stuff,
>>>> lives in
>>>> > > labs
>>>> > > - there is no change here, so proposal is that it stays the same
>>>> > >
>>>> > > [PROPOSAL]
>>>> > > org.apache.cordova.statusbar
>>>> > > - a status bar plugin for Android, iOS, and Windows Phone, lives in
>>>> core,
>>>> > > maintained by at least Jesse
>>>> > > - statusbar namespace changes, and it get's own repo possibly
>>>> > >
>>>> > > To discuss further ( in their own threads )
>>>> > > - default plugins, really just one plugin with dependencies
>>>> > > - expected intrinsic functionality, console.log?
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > >
>>>> > > @purplecabbage
>>>> > > risingj.com
>>>> > >
>>>> > >
>>>> > > On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
>>>> > >
>>>> > > > I like this idea. Achieves all concerns. (Separation thereof, and
>>>> > > > onboarding ease.)
>>>> > > >
>>>> > > >
>>>> > > > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <
>>>> csantana23@gmail.com
>>>> > > > >wrote:
>>>> > > >
>>>> > > > > +1 Keep it as a plugin not embed into platform repo
>>>> > > > >
>>>> > > > > default plugins ?
>>>> > > > >
>>>> > > > > what about binding a set of default plugins with our www
>>>> template app
>>>> > > > (the
>>>> > > > > template app specified what plugins are required)
>>>> > > > >
>>>> > > > > meaning associate a set of plugins with a template www app, and
>>>> not
>>>> > > > > associate with platform or cli
>>>> > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <
>>>> > agrieve@chromium.org
>>>> > > > > >wrote:
>>>> > > > >
>>>> > > > > > Plugins allow us to share JS. Rolling statusbar into platforms
>>>> > means
>>>> > > > > > different JS for all platforms, and make it easier for the
>>>> APIs to
>>>> > > > > diverge.
>>>> > > > > >
>>>> > > > > > Plugins allow us to share docs, and to have the docs live
>>>> with the
>>>> > > > code.
>>>> > > > > > APIs like Android's "app" plugin don't have very good docs (or
>>>> > maybe
>>>> > > > they
>>>> > > > > > are just undiscoverable, or maybe I've just missed where they
>>>> are).
>>>> > > But
>>>> > > > > > having consistency with docs is a big win I think, so having
>>>> > > statusbar
>>>> > > > > as a
>>>> > > > > > plugin means devs can go to its plugin page to find its docs.
>>>> > > > > >
>>>> > > > > > I think just having default plugins would achieve the
>>>> "everyone
>>>> > will
>>>> > > > > > probably want it" concern. But having it show up in "cordova
>>>> plugin
>>>> > > ls"
>>>> > > > > > will help devs discover that it's there and that they should
>>>> > probably
>>>> > > > use
>>>> > > > > > it.
>>>> > > > > >
>>>> > > > > >
>>>> > > > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
>>>> > > > > > jbondc@gdesolutions.com> wrote:
>>>> > > > > >
>>>> > > > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
>>>> > > > > > > > More on the concept of rolling into a platform ...
>>>> > > > > > > > My distinction is that there are some things that every
>>>> > platform
>>>> > > > > should
>>>> > > > > > > consider a
>>>> > > > > > > > baseline of browser functionality, and if the OS SDKs do
>>>> not
>>>> > > > provide
>>>> > > > > it
>>>> > > > > > > out of the
>>>> > > > > > > > box, then we should. Some examples of this :
>>>> > > > > > > >
>>>> > > > > > > > 1. Local XHR, Windows Phone does not support xhr when
>>>> trying to
>>>> > > > > access
>>>> > > > > > a
>>>> > > > > > > file://
>>>> > > > > > > > url, I could have made this a plugin that would only be
>>>> used on
>>>> > > WP,
>>>> > > > > but
>>>> > > > > > > I think
>>>> > > > > > > > this functionality should be intrinsic, so now it is.
>>>> > > > > > >
>>>> > > > > > > +1
>>>> > > > > > >
>>>> > > > > > > > 2. console.log: if you create a brand new iOS cordova
>>>> project,
>>>> > > the
>>>> > > > > > > hello-world app
>>>> > > > > > > > gives you some boilerplate code to get started. One
>>>> thing that
>>>> > > new
>>>> > > > > > > users may
>>>> > > > > > > > notice is the use of console.log in index.js, however,
>>>> they
>>>> > will
>>>> > > > > never
>>>> > > > > > > see the
>>>> > > > > > > > output. Hooking conosle.log output to go to the
>>>> command-line
>>>> > > > output
>>>> > > > > of
>>>> > > > > > > a run
>>>> > > > > > > > command, or the output window of visual studio, or xcode
>>>> is the
>>>> > > > > minimum
>>>> > > > > > > > functionality, and I personally think it should be built
>>>> in.
>>>> > This
>>>> > > > is
>>>> > > > > > > probably best
>>>> > > > > > > > discussed in a new thread, as I know Michal has a
>>>> different
>>>> > > > opinion,
>>>> > > > > > > because of
>>>> > > > > > > > some weinre edge case, but this is meant to serve more as
>>>> an
>>>> > > > example.
>>>> > > > > > > >
>>>> > > > > > >
>>>> > > > > > > Yep agree, distinction here is there's ~ "web dev" flow and
>>>> > "native
>>>> > > > > dev"
>>>> > > > > > > flow (using an IDE)
>>>> > > > > > >
>>>> > > > > > > Both of those should be core somehow
>>>> > > > > > >
>>>> > > > > > >
>>>> > > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > > --
>>>> > > > > Carlos Santana
>>>> > > > > <cs...@gmail.com>
>>>> > > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Shazron <sh...@gmail.com>.
cordova-statusbar created, that was fast. I'm migrating the statusbar
folder to that repo now.
On Thu, Mar 13, 2014 at 12:35 PM, Shazron <sh...@gmail.com> wrote:
> https://issues.apache.org/jira/browse/INFRA-7444
>
>
> On Thu, Mar 13, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
>
>> Alright, I'm going to start on this today:
>>
>> org.apache.cordova.keyboard stays in cordova-plugins but has a new
>> namespace: org.apache.cordova.labs.keyboard
>> org.apache.cordova.statusbar stays in cordova-plugins *for now* until we
>> get a new repo, and keeps its existing namespace
>>
>>
>> On Tue, Mar 11, 2014 at 11:55 AM, Jesse <pu...@gmail.com> wrote:
>>
>>> oops, yeah Shaz. "statusbar namespace does *not* change"
>>>
>>> @purplecabbage
>>> risingj.com
>>>
>>>
>>> On Tue, Mar 11, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
>>>
>>> > The proposal looks good to me. Since the majority of the code for the
>>> two
>>> > plugins have been contributed by me, I will continue to help maintain
>>> them.
>>> > One thing though -- "statusbar namespace changes" -- I believe you
>>> wanted
>>> > to say "statusbar namespace does *not* change"
>>> >
>>> >
>>> >
>>> >
>>> > On Tue, Mar 11, 2014 at 11:01 AM, Jesse <pu...@gmail.com>
>>> wrote:
>>> >
>>> > > Andrew, I agree with all of that, and never suggested that statusbar
>>> not
>>> > be
>>> > > a plugin.
>>> > >
>>> > > Attempting to rescue this thread into something we can do? ...
>>> > >
>>> > >
>>> > >
>>> > > Plugins:
>>> > > [PROPOSAL]
>>> > > org.apache.cordova.labs.keyboard
>>> > > - a iOS only keyboard plugin doing some very iOS specific stuff,
>>> lives in
>>> > > labs
>>> > > - there is no change here, so proposal is that it stays the same
>>> > >
>>> > > [PROPOSAL]
>>> > > org.apache.cordova.statusbar
>>> > > - a status bar plugin for Android, iOS, and Windows Phone, lives in
>>> core,
>>> > > maintained by at least Jesse
>>> > > - statusbar namespace changes, and it get's own repo possibly
>>> > >
>>> > > To discuss further ( in their own threads )
>>> > > - default plugins, really just one plugin with dependencies
>>> > > - expected intrinsic functionality, console.log?
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > @purplecabbage
>>> > > risingj.com
>>> > >
>>> > >
>>> > > On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
>>> > >
>>> > > > I like this idea. Achieves all concerns. (Separation thereof, and
>>> > > > onboarding ease.)
>>> > > >
>>> > > >
>>> > > > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <
>>> csantana23@gmail.com
>>> > > > >wrote:
>>> > > >
>>> > > > > +1 Keep it as a plugin not embed into platform repo
>>> > > > >
>>> > > > > default plugins ?
>>> > > > >
>>> > > > > what about binding a set of default plugins with our www
>>> template app
>>> > > > (the
>>> > > > > template app specified what plugins are required)
>>> > > > >
>>> > > > > meaning associate a set of plugins with a template www app, and
>>> not
>>> > > > > associate with platform or cli
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <
>>> > agrieve@chromium.org
>>> > > > > >wrote:
>>> > > > >
>>> > > > > > Plugins allow us to share JS. Rolling statusbar into platforms
>>> > means
>>> > > > > > different JS for all platforms, and make it easier for the
>>> APIs to
>>> > > > > diverge.
>>> > > > > >
>>> > > > > > Plugins allow us to share docs, and to have the docs live with
>>> the
>>> > > > code.
>>> > > > > > APIs like Android's "app" plugin don't have very good docs (or
>>> > maybe
>>> > > > they
>>> > > > > > are just undiscoverable, or maybe I've just missed where they
>>> are).
>>> > > But
>>> > > > > > having consistency with docs is a big win I think, so having
>>> > > statusbar
>>> > > > > as a
>>> > > > > > plugin means devs can go to its plugin page to find its docs.
>>> > > > > >
>>> > > > > > I think just having default plugins would achieve the "everyone
>>> > will
>>> > > > > > probably want it" concern. But having it show up in "cordova
>>> plugin
>>> > > ls"
>>> > > > > > will help devs discover that it's there and that they should
>>> > probably
>>> > > > use
>>> > > > > > it.
>>> > > > > >
>>> > > > > >
>>> > > > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
>>> > > > > > jbondc@gdesolutions.com> wrote:
>>> > > > > >
>>> > > > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
>>> > > > > > > > More on the concept of rolling into a platform ...
>>> > > > > > > > My distinction is that there are some things that every
>>> > platform
>>> > > > > should
>>> > > > > > > consider a
>>> > > > > > > > baseline of browser functionality, and if the OS SDKs do
>>> not
>>> > > > provide
>>> > > > > it
>>> > > > > > > out of the
>>> > > > > > > > box, then we should. Some examples of this :
>>> > > > > > > >
>>> > > > > > > > 1. Local XHR, Windows Phone does not support xhr when
>>> trying to
>>> > > > > access
>>> > > > > > a
>>> > > > > > > file://
>>> > > > > > > > url, I could have made this a plugin that would only be
>>> used on
>>> > > WP,
>>> > > > > but
>>> > > > > > > I think
>>> > > > > > > > this functionality should be intrinsic, so now it is.
>>> > > > > > >
>>> > > > > > > +1
>>> > > > > > >
>>> > > > > > > > 2. console.log: if you create a brand new iOS cordova
>>> project,
>>> > > the
>>> > > > > > > hello-world app
>>> > > > > > > > gives you some boilerplate code to get started. One thing
>>> that
>>> > > new
>>> > > > > > > users may
>>> > > > > > > > notice is the use of console.log in index.js, however, they
>>> > will
>>> > > > > never
>>> > > > > > > see the
>>> > > > > > > > output. Hooking conosle.log output to go to the
>>> command-line
>>> > > > output
>>> > > > > of
>>> > > > > > > a run
>>> > > > > > > > command, or the output window of visual studio, or xcode
>>> is the
>>> > > > > minimum
>>> > > > > > > > functionality, and I personally think it should be built
>>> in.
>>> > This
>>> > > > is
>>> > > > > > > probably best
>>> > > > > > > > discussed in a new thread, as I know Michal has a different
>>> > > > opinion,
>>> > > > > > > because of
>>> > > > > > > > some weinre edge case, but this is meant to serve more as
>>> an
>>> > > > example.
>>> > > > > > > >
>>> > > > > > >
>>> > > > > > > Yep agree, distinction here is there's ~ "web dev" flow and
>>> > "native
>>> > > > > dev"
>>> > > > > > > flow (using an IDE)
>>> > > > > > >
>>> > > > > > > Both of those should be core somehow
>>> > > > > > >
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > --
>>> > > > > Carlos Santana
>>> > > > > <cs...@gmail.com>
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Shazron <sh...@gmail.com>.
https://issues.apache.org/jira/browse/INFRA-7444
On Thu, Mar 13, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
> Alright, I'm going to start on this today:
>
> org.apache.cordova.keyboard stays in cordova-plugins but has a new
> namespace: org.apache.cordova.labs.keyboard
> org.apache.cordova.statusbar stays in cordova-plugins *for now* until we
> get a new repo, and keeps its existing namespace
>
>
> On Tue, Mar 11, 2014 at 11:55 AM, Jesse <pu...@gmail.com> wrote:
>
>> oops, yeah Shaz. "statusbar namespace does *not* change"
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Tue, Mar 11, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
>>
>> > The proposal looks good to me. Since the majority of the code for the
>> two
>> > plugins have been contributed by me, I will continue to help maintain
>> them.
>> > One thing though -- "statusbar namespace changes" -- I believe you
>> wanted
>> > to say "statusbar namespace does *not* change"
>> >
>> >
>> >
>> >
>> > On Tue, Mar 11, 2014 at 11:01 AM, Jesse <pu...@gmail.com>
>> wrote:
>> >
>> > > Andrew, I agree with all of that, and never suggested that statusbar
>> not
>> > be
>> > > a plugin.
>> > >
>> > > Attempting to rescue this thread into something we can do? ...
>> > >
>> > >
>> > >
>> > > Plugins:
>> > > [PROPOSAL]
>> > > org.apache.cordova.labs.keyboard
>> > > - a iOS only keyboard plugin doing some very iOS specific stuff,
>> lives in
>> > > labs
>> > > - there is no change here, so proposal is that it stays the same
>> > >
>> > > [PROPOSAL]
>> > > org.apache.cordova.statusbar
>> > > - a status bar plugin for Android, iOS, and Windows Phone, lives in
>> core,
>> > > maintained by at least Jesse
>> > > - statusbar namespace changes, and it get's own repo possibly
>> > >
>> > > To discuss further ( in their own threads )
>> > > - default plugins, really just one plugin with dependencies
>> > > - expected intrinsic functionality, console.log?
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > @purplecabbage
>> > > risingj.com
>> > >
>> > >
>> > > On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
>> > >
>> > > > I like this idea. Achieves all concerns. (Separation thereof, and
>> > > > onboarding ease.)
>> > > >
>> > > >
>> > > > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <
>> csantana23@gmail.com
>> > > > >wrote:
>> > > >
>> > > > > +1 Keep it as a plugin not embed into platform repo
>> > > > >
>> > > > > default plugins ?
>> > > > >
>> > > > > what about binding a set of default plugins with our www template
>> app
>> > > > (the
>> > > > > template app specified what plugins are required)
>> > > > >
>> > > > > meaning associate a set of plugins with a template www app, and
>> not
>> > > > > associate with platform or cli
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <
>> > agrieve@chromium.org
>> > > > > >wrote:
>> > > > >
>> > > > > > Plugins allow us to share JS. Rolling statusbar into platforms
>> > means
>> > > > > > different JS for all platforms, and make it easier for the APIs
>> to
>> > > > > diverge.
>> > > > > >
>> > > > > > Plugins allow us to share docs, and to have the docs live with
>> the
>> > > > code.
>> > > > > > APIs like Android's "app" plugin don't have very good docs (or
>> > maybe
>> > > > they
>> > > > > > are just undiscoverable, or maybe I've just missed where they
>> are).
>> > > But
>> > > > > > having consistency with docs is a big win I think, so having
>> > > statusbar
>> > > > > as a
>> > > > > > plugin means devs can go to its plugin page to find its docs.
>> > > > > >
>> > > > > > I think just having default plugins would achieve the "everyone
>> > will
>> > > > > > probably want it" concern. But having it show up in "cordova
>> plugin
>> > > ls"
>> > > > > > will help devs discover that it's there and that they should
>> > probably
>> > > > use
>> > > > > > it.
>> > > > > >
>> > > > > >
>> > > > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
>> > > > > > jbondc@gdesolutions.com> wrote:
>> > > > > >
>> > > > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
>> > > > > > > > More on the concept of rolling into a platform ...
>> > > > > > > > My distinction is that there are some things that every
>> > platform
>> > > > > should
>> > > > > > > consider a
>> > > > > > > > baseline of browser functionality, and if the OS SDKs do not
>> > > > provide
>> > > > > it
>> > > > > > > out of the
>> > > > > > > > box, then we should. Some examples of this :
>> > > > > > > >
>> > > > > > > > 1. Local XHR, Windows Phone does not support xhr when
>> trying to
>> > > > > access
>> > > > > > a
>> > > > > > > file://
>> > > > > > > > url, I could have made this a plugin that would only be
>> used on
>> > > WP,
>> > > > > but
>> > > > > > > I think
>> > > > > > > > this functionality should be intrinsic, so now it is.
>> > > > > > >
>> > > > > > > +1
>> > > > > > >
>> > > > > > > > 2. console.log: if you create a brand new iOS cordova
>> project,
>> > > the
>> > > > > > > hello-world app
>> > > > > > > > gives you some boilerplate code to get started. One thing
>> that
>> > > new
>> > > > > > > users may
>> > > > > > > > notice is the use of console.log in index.js, however, they
>> > will
>> > > > > never
>> > > > > > > see the
>> > > > > > > > output. Hooking conosle.log output to go to the
>> command-line
>> > > > output
>> > > > > of
>> > > > > > > a run
>> > > > > > > > command, or the output window of visual studio, or xcode is
>> the
>> > > > > minimum
>> > > > > > > > functionality, and I personally think it should be built in.
>> > This
>> > > > is
>> > > > > > > probably best
>> > > > > > > > discussed in a new thread, as I know Michal has a different
>> > > > opinion,
>> > > > > > > because of
>> > > > > > > > some weinre edge case, but this is meant to serve more as an
>> > > > example.
>> > > > > > > >
>> > > > > > >
>> > > > > > > Yep agree, distinction here is there's ~ "web dev" flow and
>> > "native
>> > > > > dev"
>> > > > > > > flow (using an IDE)
>> > > > > > >
>> > > > > > > Both of those should be core somehow
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Carlos Santana
>> > > > > <cs...@gmail.com>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Shazron <sh...@gmail.com>.
Alright, I'm going to start on this today:
org.apache.cordova.keyboard stays in cordova-plugins but has a new
namespace: org.apache.cordova.labs.keyboard
org.apache.cordova.statusbar stays in cordova-plugins *for now* until we
get a new repo, and keeps its existing namespace
On Tue, Mar 11, 2014 at 11:55 AM, Jesse <pu...@gmail.com> wrote:
> oops, yeah Shaz. "statusbar namespace does *not* change"
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Mar 11, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
>
> > The proposal looks good to me. Since the majority of the code for the two
> > plugins have been contributed by me, I will continue to help maintain
> them.
> > One thing though -- "statusbar namespace changes" -- I believe you wanted
> > to say "statusbar namespace does *not* change"
> >
> >
> >
> >
> > On Tue, Mar 11, 2014 at 11:01 AM, Jesse <pu...@gmail.com> wrote:
> >
> > > Andrew, I agree with all of that, and never suggested that statusbar
> not
> > be
> > > a plugin.
> > >
> > > Attempting to rescue this thread into something we can do? ...
> > >
> > >
> > >
> > > Plugins:
> > > [PROPOSAL]
> > > org.apache.cordova.labs.keyboard
> > > - a iOS only keyboard plugin doing some very iOS specific stuff, lives
> in
> > > labs
> > > - there is no change here, so proposal is that it stays the same
> > >
> > > [PROPOSAL]
> > > org.apache.cordova.statusbar
> > > - a status bar plugin for Android, iOS, and Windows Phone, lives in
> core,
> > > maintained by at least Jesse
> > > - statusbar namespace changes, and it get's own repo possibly
> > >
> > > To discuss further ( in their own threads )
> > > - default plugins, really just one plugin with dependencies
> > > - expected intrinsic functionality, console.log?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > I like this idea. Achieves all concerns. (Separation thereof, and
> > > > onboarding ease.)
> > > >
> > > >
> > > > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <
> csantana23@gmail.com
> > > > >wrote:
> > > >
> > > > > +1 Keep it as a plugin not embed into platform repo
> > > > >
> > > > > default plugins ?
> > > > >
> > > > > what about binding a set of default plugins with our www template
> app
> > > > (the
> > > > > template app specified what plugins are required)
> > > > >
> > > > > meaning associate a set of plugins with a template www app, and not
> > > > > associate with platform or cli
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <
> > agrieve@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > Plugins allow us to share JS. Rolling statusbar into platforms
> > means
> > > > > > different JS for all platforms, and make it easier for the APIs
> to
> > > > > diverge.
> > > > > >
> > > > > > Plugins allow us to share docs, and to have the docs live with
> the
> > > > code.
> > > > > > APIs like Android's "app" plugin don't have very good docs (or
> > maybe
> > > > they
> > > > > > are just undiscoverable, or maybe I've just missed where they
> are).
> > > But
> > > > > > having consistency with docs is a big win I think, so having
> > > statusbar
> > > > > as a
> > > > > > plugin means devs can go to its plugin page to find its docs.
> > > > > >
> > > > > > I think just having default plugins would achieve the "everyone
> > will
> > > > > > probably want it" concern. But having it show up in "cordova
> plugin
> > > ls"
> > > > > > will help devs discover that it's there and that they should
> > probably
> > > > use
> > > > > > it.
> > > > > >
> > > > > >
> > > > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > > > > jbondc@gdesolutions.com> wrote:
> > > > > >
> > > > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > > > > More on the concept of rolling into a platform ...
> > > > > > > > My distinction is that there are some things that every
> > platform
> > > > > should
> > > > > > > consider a
> > > > > > > > baseline of browser functionality, and if the OS SDKs do not
> > > > provide
> > > > > it
> > > > > > > out of the
> > > > > > > > box, then we should. Some examples of this :
> > > > > > > >
> > > > > > > > 1. Local XHR, Windows Phone does not support xhr when trying
> to
> > > > > access
> > > > > > a
> > > > > > > file://
> > > > > > > > url, I could have made this a plugin that would only be used
> on
> > > WP,
> > > > > but
> > > > > > > I think
> > > > > > > > this functionality should be intrinsic, so now it is.
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > > 2. console.log: if you create a brand new iOS cordova
> project,
> > > the
> > > > > > > hello-world app
> > > > > > > > gives you some boilerplate code to get started. One thing
> that
> > > new
> > > > > > > users may
> > > > > > > > notice is the use of console.log in index.js, however, they
> > will
> > > > > never
> > > > > > > see the
> > > > > > > > output. Hooking conosle.log output to go to the command-line
> > > > output
> > > > > of
> > > > > > > a run
> > > > > > > > command, or the output window of visual studio, or xcode is
> the
> > > > > minimum
> > > > > > > > functionality, and I personally think it should be built in.
> > This
> > > > is
> > > > > > > probably best
> > > > > > > > discussed in a new thread, as I know Michal has a different
> > > > opinion,
> > > > > > > because of
> > > > > > > > some weinre edge case, but this is meant to serve more as an
> > > > example.
> > > > > > > >
> > > > > > >
> > > > > > > Yep agree, distinction here is there's ~ "web dev" flow and
> > "native
> > > > > dev"
> > > > > > > flow (using an IDE)
> > > > > > >
> > > > > > > Both of those should be core somehow
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Carlos Santana
> > > > > <cs...@gmail.com>
> > > > >
> > > >
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Jesse <pu...@gmail.com>.
oops, yeah Shaz. "statusbar namespace does *not* change"
@purplecabbage
risingj.com
On Tue, Mar 11, 2014 at 11:50 AM, Shazron <sh...@gmail.com> wrote:
> The proposal looks good to me. Since the majority of the code for the two
> plugins have been contributed by me, I will continue to help maintain them.
> One thing though -- "statusbar namespace changes" -- I believe you wanted
> to say "statusbar namespace does *not* change"
>
>
>
>
> On Tue, Mar 11, 2014 at 11:01 AM, Jesse <pu...@gmail.com> wrote:
>
> > Andrew, I agree with all of that, and never suggested that statusbar not
> be
> > a plugin.
> >
> > Attempting to rescue this thread into something we can do? ...
> >
> >
> >
> > Plugins:
> > [PROPOSAL]
> > org.apache.cordova.labs.keyboard
> > - a iOS only keyboard plugin doing some very iOS specific stuff, lives in
> > labs
> > - there is no change here, so proposal is that it stays the same
> >
> > [PROPOSAL]
> > org.apache.cordova.statusbar
> > - a status bar plugin for Android, iOS, and Windows Phone, lives in core,
> > maintained by at least Jesse
> > - statusbar namespace changes, and it get's own repo possibly
> >
> > To discuss further ( in their own threads )
> > - default plugins, really just one plugin with dependencies
> > - expected intrinsic functionality, console.log?
> >
> >
> >
> >
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > I like this idea. Achieves all concerns. (Separation thereof, and
> > > onboarding ease.)
> > >
> > >
> > > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <csantana23@gmail.com
> > > >wrote:
> > >
> > > > +1 Keep it as a plugin not embed into platform repo
> > > >
> > > > default plugins ?
> > > >
> > > > what about binding a set of default plugins with our www template app
> > > (the
> > > > template app specified what plugins are required)
> > > >
> > > > meaning associate a set of plugins with a template www app, and not
> > > > associate with platform or cli
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <
> agrieve@chromium.org
> > > > >wrote:
> > > >
> > > > > Plugins allow us to share JS. Rolling statusbar into platforms
> means
> > > > > different JS for all platforms, and make it easier for the APIs to
> > > > diverge.
> > > > >
> > > > > Plugins allow us to share docs, and to have the docs live with the
> > > code.
> > > > > APIs like Android's "app" plugin don't have very good docs (or
> maybe
> > > they
> > > > > are just undiscoverable, or maybe I've just missed where they are).
> > But
> > > > > having consistency with docs is a big win I think, so having
> > statusbar
> > > > as a
> > > > > plugin means devs can go to its plugin page to find its docs.
> > > > >
> > > > > I think just having default plugins would achieve the "everyone
> will
> > > > > probably want it" concern. But having it show up in "cordova plugin
> > ls"
> > > > > will help devs discover that it's there and that they should
> probably
> > > use
> > > > > it.
> > > > >
> > > > >
> > > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > > > jbondc@gdesolutions.com> wrote:
> > > > >
> > > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > > > More on the concept of rolling into a platform ...
> > > > > > > My distinction is that there are some things that every
> platform
> > > > should
> > > > > > consider a
> > > > > > > baseline of browser functionality, and if the OS SDKs do not
> > > provide
> > > > it
> > > > > > out of the
> > > > > > > box, then we should. Some examples of this :
> > > > > > >
> > > > > > > 1. Local XHR, Windows Phone does not support xhr when trying to
> > > > access
> > > > > a
> > > > > > file://
> > > > > > > url, I could have made this a plugin that would only be used on
> > WP,
> > > > but
> > > > > > I think
> > > > > > > this functionality should be intrinsic, so now it is.
> > > > > >
> > > > > > +1
> > > > > >
> > > > > > > 2. console.log: if you create a brand new iOS cordova project,
> > the
> > > > > > hello-world app
> > > > > > > gives you some boilerplate code to get started. One thing that
> > new
> > > > > > users may
> > > > > > > notice is the use of console.log in index.js, however, they
> will
> > > > never
> > > > > > see the
> > > > > > > output. Hooking conosle.log output to go to the command-line
> > > output
> > > > of
> > > > > > a run
> > > > > > > command, or the output window of visual studio, or xcode is the
> > > > minimum
> > > > > > > functionality, and I personally think it should be built in.
> This
> > > is
> > > > > > probably best
> > > > > > > discussed in a new thread, as I know Michal has a different
> > > opinion,
> > > > > > because of
> > > > > > > some weinre edge case, but this is meant to serve more as an
> > > example.
> > > > > > >
> > > > > >
> > > > > > Yep agree, distinction here is there's ~ "web dev" flow and
> "native
> > > > dev"
> > > > > > flow (using an IDE)
> > > > > >
> > > > > > Both of those should be core somehow
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > <cs...@gmail.com>
> > > >
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Shazron <sh...@gmail.com>.
The proposal looks good to me. Since the majority of the code for the two
plugins have been contributed by me, I will continue to help maintain them.
One thing though -- "statusbar namespace changes" -- I believe you wanted
to say "statusbar namespace does *not* change"
On Tue, Mar 11, 2014 at 11:01 AM, Jesse <pu...@gmail.com> wrote:
> Andrew, I agree with all of that, and never suggested that statusbar not be
> a plugin.
>
> Attempting to rescue this thread into something we can do? ...
>
>
>
> Plugins:
> [PROPOSAL]
> org.apache.cordova.labs.keyboard
> - a iOS only keyboard plugin doing some very iOS specific stuff, lives in
> labs
> - there is no change here, so proposal is that it stays the same
>
> [PROPOSAL]
> org.apache.cordova.statusbar
> - a status bar plugin for Android, iOS, and Windows Phone, lives in core,
> maintained by at least Jesse
> - statusbar namespace changes, and it get's own repo possibly
>
> To discuss further ( in their own threads )
> - default plugins, really just one plugin with dependencies
> - expected intrinsic functionality, console.log?
>
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > I like this idea. Achieves all concerns. (Separation thereof, and
> > onboarding ease.)
> >
> >
> > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <csantana23@gmail.com
> > >wrote:
> >
> > > +1 Keep it as a plugin not embed into platform repo
> > >
> > > default plugins ?
> > >
> > > what about binding a set of default plugins with our www template app
> > (the
> > > template app specified what plugins are required)
> > >
> > > meaning associate a set of plugins with a template www app, and not
> > > associate with platform or cli
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <agrieve@chromium.org
> > > >wrote:
> > >
> > > > Plugins allow us to share JS. Rolling statusbar into platforms means
> > > > different JS for all platforms, and make it easier for the APIs to
> > > diverge.
> > > >
> > > > Plugins allow us to share docs, and to have the docs live with the
> > code.
> > > > APIs like Android's "app" plugin don't have very good docs (or maybe
> > they
> > > > are just undiscoverable, or maybe I've just missed where they are).
> But
> > > > having consistency with docs is a big win I think, so having
> statusbar
> > > as a
> > > > plugin means devs can go to its plugin page to find its docs.
> > > >
> > > > I think just having default plugins would achieve the "everyone will
> > > > probably want it" concern. But having it show up in "cordova plugin
> ls"
> > > > will help devs discover that it's there and that they should probably
> > use
> > > > it.
> > > >
> > > >
> > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > > jbondc@gdesolutions.com> wrote:
> > > >
> > > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > > More on the concept of rolling into a platform ...
> > > > > > My distinction is that there are some things that every platform
> > > should
> > > > > consider a
> > > > > > baseline of browser functionality, and if the OS SDKs do not
> > provide
> > > it
> > > > > out of the
> > > > > > box, then we should. Some examples of this :
> > > > > >
> > > > > > 1. Local XHR, Windows Phone does not support xhr when trying to
> > > access
> > > > a
> > > > > file://
> > > > > > url, I could have made this a plugin that would only be used on
> WP,
> > > but
> > > > > I think
> > > > > > this functionality should be intrinsic, so now it is.
> > > > >
> > > > > +1
> > > > >
> > > > > > 2. console.log: if you create a brand new iOS cordova project,
> the
> > > > > hello-world app
> > > > > > gives you some boilerplate code to get started. One thing that
> new
> > > > > users may
> > > > > > notice is the use of console.log in index.js, however, they will
> > > never
> > > > > see the
> > > > > > output. Hooking conosle.log output to go to the command-line
> > output
> > > of
> > > > > a run
> > > > > > command, or the output window of visual studio, or xcode is the
> > > minimum
> > > > > > functionality, and I personally think it should be built in. This
> > is
> > > > > probably best
> > > > > > discussed in a new thread, as I know Michal has a different
> > opinion,
> > > > > because of
> > > > > > some weinre edge case, but this is meant to serve more as an
> > example.
> > > > > >
> > > > >
> > > > > Yep agree, distinction here is there's ~ "web dev" flow and "native
> > > dev"
> > > > > flow (using an IDE)
> > > > >
> > > > > Both of those should be core somehow
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > <cs...@gmail.com>
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Jesse <pu...@gmail.com>.
Andrew, I agree with all of that, and never suggested that statusbar not be
a plugin.
Attempting to rescue this thread into something we can do? ...
Plugins:
[PROPOSAL]
org.apache.cordova.labs.keyboard
- a iOS only keyboard plugin doing some very iOS specific stuff, lives in
labs
- there is no change here, so proposal is that it stays the same
[PROPOSAL]
org.apache.cordova.statusbar
- a status bar plugin for Android, iOS, and Windows Phone, lives in core,
maintained by at least Jesse
- statusbar namespace changes, and it get's own repo possibly
To discuss further ( in their own threads )
- default plugins, really just one plugin with dependencies
- expected intrinsic functionality, console.log?
@purplecabbage
risingj.com
On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote:
> I like this idea. Achieves all concerns. (Separation thereof, and
> onboarding ease.)
>
>
> On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <csantana23@gmail.com
> >wrote:
>
> > +1 Keep it as a plugin not embed into platform repo
> >
> > default plugins ?
> >
> > what about binding a set of default plugins with our www template app
> (the
> > template app specified what plugins are required)
> >
> > meaning associate a set of plugins with a template www app, and not
> > associate with platform or cli
> >
> >
> >
> >
> >
> > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > Plugins allow us to share JS. Rolling statusbar into platforms means
> > > different JS for all platforms, and make it easier for the APIs to
> > diverge.
> > >
> > > Plugins allow us to share docs, and to have the docs live with the
> code.
> > > APIs like Android's "app" plugin don't have very good docs (or maybe
> they
> > > are just undiscoverable, or maybe I've just missed where they are). But
> > > having consistency with docs is a big win I think, so having statusbar
> > as a
> > > plugin means devs can go to its plugin page to find its docs.
> > >
> > > I think just having default plugins would achieve the "everyone will
> > > probably want it" concern. But having it show up in "cordova plugin ls"
> > > will help devs discover that it's there and that they should probably
> use
> > > it.
> > >
> > >
> > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > > jbondc@gdesolutions.com> wrote:
> > >
> > > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > > More on the concept of rolling into a platform ...
> > > > > My distinction is that there are some things that every platform
> > should
> > > > consider a
> > > > > baseline of browser functionality, and if the OS SDKs do not
> provide
> > it
> > > > out of the
> > > > > box, then we should. Some examples of this :
> > > > >
> > > > > 1. Local XHR, Windows Phone does not support xhr when trying to
> > access
> > > a
> > > > file://
> > > > > url, I could have made this a plugin that would only be used on WP,
> > but
> > > > I think
> > > > > this functionality should be intrinsic, so now it is.
> > > >
> > > > +1
> > > >
> > > > > 2. console.log: if you create a brand new iOS cordova project, the
> > > > hello-world app
> > > > > gives you some boilerplate code to get started. One thing that new
> > > > users may
> > > > > notice is the use of console.log in index.js, however, they will
> > never
> > > > see the
> > > > > output. Hooking conosle.log output to go to the command-line
> output
> > of
> > > > a run
> > > > > command, or the output window of visual studio, or xcode is the
> > minimum
> > > > > functionality, and I personally think it should be built in. This
> is
> > > > probably best
> > > > > discussed in a new thread, as I know Michal has a different
> opinion,
> > > > because of
> > > > > some weinre edge case, but this is meant to serve more as an
> example.
> > > > >
> > > >
> > > > Yep agree, distinction here is there's ~ "web dev" flow and "native
> > dev"
> > > > flow (using an IDE)
> > > >
> > > > Both of those should be core somehow
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Brian LeRoux <b...@brian.io>.
I like this idea. Achieves all concerns. (Separation thereof, and
onboarding ease.)
On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana <cs...@gmail.com>wrote:
> +1 Keep it as a plugin not embed into platform repo
>
> default plugins ?
>
> what about binding a set of default plugins with our www template app (the
> template app specified what plugins are required)
>
> meaning associate a set of plugins with a template www app, and not
> associate with platform or cli
>
>
>
>
>
> On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Plugins allow us to share JS. Rolling statusbar into platforms means
> > different JS for all platforms, and make it easier for the APIs to
> diverge.
> >
> > Plugins allow us to share docs, and to have the docs live with the code.
> > APIs like Android's "app" plugin don't have very good docs (or maybe they
> > are just undiscoverable, or maybe I've just missed where they are). But
> > having consistency with docs is a big win I think, so having statusbar
> as a
> > plugin means devs can go to its plugin page to find its docs.
> >
> > I think just having default plugins would achieve the "everyone will
> > probably want it" concern. But having it show up in "cordova plugin ls"
> > will help devs discover that it's there and that they should probably use
> > it.
> >
> >
> > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> > jbondc@gdesolutions.com> wrote:
> >
> > > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > > More on the concept of rolling into a platform ...
> > > > My distinction is that there are some things that every platform
> should
> > > consider a
> > > > baseline of browser functionality, and if the OS SDKs do not provide
> it
> > > out of the
> > > > box, then we should. Some examples of this :
> > > >
> > > > 1. Local XHR, Windows Phone does not support xhr when trying to
> access
> > a
> > > file://
> > > > url, I could have made this a plugin that would only be used on WP,
> but
> > > I think
> > > > this functionality should be intrinsic, so now it is.
> > >
> > > +1
> > >
> > > > 2. console.log: if you create a brand new iOS cordova project, the
> > > hello-world app
> > > > gives you some boilerplate code to get started. One thing that new
> > > users may
> > > > notice is the use of console.log in index.js, however, they will
> never
> > > see the
> > > > output. Hooking conosle.log output to go to the command-line output
> of
> > > a run
> > > > command, or the output window of visual studio, or xcode is the
> minimum
> > > > functionality, and I personally think it should be built in. This is
> > > probably best
> > > > discussed in a new thread, as I know Michal has a different opinion,
> > > because of
> > > > some weinre edge case, but this is meant to serve more as an example.
> > > >
> > >
> > > Yep agree, distinction here is there's ~ "web dev" flow and "native
> dev"
> > > flow (using an IDE)
> > >
> > > Both of those should be core somehow
> > >
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Carlos Santana <cs...@gmail.com>.
+1 Keep it as a plugin not embed into platform repo
default plugins ?
what about binding a set of default plugins with our www template app (the
template app specified what plugins are required)
meaning associate a set of plugins with a template www app, and not
associate with platform or cli
On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve <ag...@chromium.org>wrote:
> Plugins allow us to share JS. Rolling statusbar into platforms means
> different JS for all platforms, and make it easier for the APIs to diverge.
>
> Plugins allow us to share docs, and to have the docs live with the code.
> APIs like Android's "app" plugin don't have very good docs (or maybe they
> are just undiscoverable, or maybe I've just missed where they are). But
> having consistency with docs is a big win I think, so having statusbar as a
> plugin means devs can go to its plugin page to find its docs.
>
> I think just having default plugins would achieve the "everyone will
> probably want it" concern. But having it show up in "cordova plugin ls"
> will help devs discover that it's there and that they should probably use
> it.
>
>
> On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
> > On Mon Mar 10 04:07 PM, Jesse wrote:
> > > More on the concept of rolling into a platform ...
> > > My distinction is that there are some things that every platform should
> > consider a
> > > baseline of browser functionality, and if the OS SDKs do not provide it
> > out of the
> > > box, then we should. Some examples of this :
> > >
> > > 1. Local XHR, Windows Phone does not support xhr when trying to access
> a
> > file://
> > > url, I could have made this a plugin that would only be used on WP, but
> > I think
> > > this functionality should be intrinsic, so now it is.
> >
> > +1
> >
> > > 2. console.log: if you create a brand new iOS cordova project, the
> > hello-world app
> > > gives you some boilerplate code to get started. One thing that new
> > users may
> > > notice is the use of console.log in index.js, however, they will never
> > see the
> > > output. Hooking conosle.log output to go to the command-line output of
> > a run
> > > command, or the output window of visual studio, or xcode is the minimum
> > > functionality, and I personally think it should be built in. This is
> > probably best
> > > discussed in a new thread, as I know Michal has a different opinion,
> > because of
> > > some weinre edge case, but this is meant to serve more as an example.
> > >
> >
> > Yep agree, distinction here is there's ~ "web dev" flow and "native dev"
> > flow (using an IDE)
> >
> > Both of those should be core somehow
> >
> >
>
--
Carlos Santana
<cs...@gmail.com>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Andrew Grieve <ag...@chromium.org>.
Plugins allow us to share JS. Rolling statusbar into platforms means
different JS for all platforms, and make it easier for the APIs to diverge.
Plugins allow us to share docs, and to have the docs live with the code.
APIs like Android's "app" plugin don't have very good docs (or maybe they
are just undiscoverable, or maybe I've just missed where they are). But
having consistency with docs is a big win I think, so having statusbar as a
plugin means devs can go to its plugin page to find its docs.
I think just having default plugins would achieve the "everyone will
probably want it" concern. But having it show up in "cordova plugin ls"
will help devs discover that it's there and that they should probably use
it.
On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Mon Mar 10 04:07 PM, Jesse wrote:
> > More on the concept of rolling into a platform ...
> > My distinction is that there are some things that every platform should
> consider a
> > baseline of browser functionality, and if the OS SDKs do not provide it
> out of the
> > box, then we should. Some examples of this :
> >
> > 1. Local XHR, Windows Phone does not support xhr when trying to access a
> file://
> > url, I could have made this a plugin that would only be used on WP, but
> I think
> > this functionality should be intrinsic, so now it is.
>
> +1
>
> > 2. console.log: if you create a brand new iOS cordova project, the
> hello-world app
> > gives you some boilerplate code to get started. One thing that new
> users may
> > notice is the use of console.log in index.js, however, they will never
> see the
> > output. Hooking conosle.log output to go to the command-line output of
> a run
> > command, or the output window of visual studio, or xcode is the minimum
> > functionality, and I personally think it should be built in. This is
> probably best
> > discussed in a new thread, as I know Michal has a different opinion,
> because of
> > some weinre edge case, but this is meant to serve more as an example.
> >
>
> Yep agree, distinction here is there's ~ "web dev" flow and "native dev"
> flow (using an IDE)
>
> Both of those should be core somehow
>
>
RE: [cordova-plugins/statusbar] Publishing as core
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Mon Mar 10 04:07 PM, Jesse wrote:
> More on the concept of rolling into a platform ...
> My distinction is that there are some things that every platform should consider a
> baseline of browser functionality, and if the OS SDKs do not provide it out of the
> box, then we should. Some examples of this :
>
> 1. Local XHR, Windows Phone does not support xhr when trying to access a file://
> url, I could have made this a plugin that would only be used on WP, but I think
> this functionality should be intrinsic, so now it is.
+1
> 2. console.log: if you create a brand new iOS cordova project, the hello-world app
> gives you some boilerplate code to get started. One thing that new users may
> notice is the use of console.log in index.js, however, they will never see the
> output. Hooking conosle.log output to go to the command-line output of a run
> command, or the output window of visual studio, or xcode is the minimum
> functionality, and I personally think it should be built in. This is probably best
> discussed in a new thread, as I know Michal has a different opinion, because of
> some weinre edge case, but this is meant to serve more as an example.
>
Yep agree, distinction here is there's ~ "web dev" flow and "native dev" flow (using an IDE)
Both of those should be core somehow
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Michal Mocny <mm...@chromium.org>.
On Mon, Mar 10, 2014 at 4:07 PM, Jesse <pu...@gmail.com> wrote:
> More on the concept of rolling into a platform ...
> My distinction is that there are some things that every platform should
> consider a baseline of browser functionality, and if the OS SDKs do not
> provide it out of the box, then we should. Some examples of this :
>
> 1. Local XHR, Windows Phone does not support xhr when trying to access a
> file:// url, I could have made this a plugin that would only be used on WP,
> but I think this functionality should be intrinsic, so now it is.
> 2. console.log: if you create a brand new iOS cordova project, the
> hello-world app gives you some boilerplate code to get started. One thing
> that new users may notice is the use of console.log in index.js, however,
> they will never see the output. Hooking conosle.log output to go to the
> command-line output of a run command, or the output window of visual
> studio, or xcode is the minimum functionality, and I personally think it
> should be built in. This is probably best discussed in a new thread, as I
> know Michal has a different opinion, because of some weinre edge case, but
> this is meant to serve more as an example.
>
New Thread sounds better, but wanted to just point out: its not weinre, its
safari remote inspector, I wouldn't make a fuss if it was just weinre
(sorry Patrick!).
>
> What is core?:
> Core used to mean everything that we built in, now I think it means
> everything that we ship,
>
> >> Does "core" mean that it has the namespace "org.apache.cordova."?
> >> Does "core" mean that it is something we will support?
> >> Does "core" mean that it is something that applies to multiple
> platforms?
>
> I think it means all of these things.
>
> Back to the original subject :
>
> I think keyboard makes the most sense in org.apache.cordova.labs, or built
> right into the platform, it does not have wide enough reach to be 'core' in
> my opinion. Inclusion in the cordova-ios directly is probably a subject to
> the following questions :
> - how important is it? Can apps live without it?
> - is there ever a reason to NOT use this?
> - will it ever make sense for other platforms to implement the same APIs?
>
> org.apache.cordova.statusbar
> I think statusbar makes sense as a 'core' plugin, because it is implemented
> for iOS/Android and WP7/8. Some of the APIs are currently very iOS
> specific, but that is a topic for another thread.
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Mar 10, 2014 at 12:05 PM, Tommy-Carlos Williams
> <to...@devgeeks.org>wrote:
>
> > +1
> >
> >
> > On 11 Mar 2014, at 5:52 am, Brian LeRoux <b...@brian.io> wrote:
> >
> > > While I wholeheartedly agree plugins, clean separation of concerns,
> > > discreet repos, all have big benefits if every single developer
> installs
> > a
> > > plugin on day 1 that is specific to a particular platform I feel that
> > might
> > > be a good indication the platform should conditionally roll that plugin
> > in.
> > > I think the statusbar might quality.
> > >
> > >
> > >
> > >
> > > On Mon, Mar 10, 2014 at 10:30 AM, Jonathan Bond-Caron <
> > > jbondc@gdesolutions.com> wrote:
> > >
> > >> On Mon Mar 10 12:51 PM, Michal Mocny wrote:
> > >>>
> > >>> I think we can solve that problem using a plethora of better
> > >>> alternatives, including
> > >>> install scripts (perhaps with a generator
> > >>> like yeoman, perhaps my just pasting
> > >>> snippets in tutorials), by
> > >>> supporting plugin dependencies for platforms, or just by
> > >>> hard coding
> > >>> a list of default plugins in cordova-cli (we do this in cca for
> > >>> example).
> > >>> Many alternatives exist.
> > >>>
> > >>
> > >> Kind of agree, I like the idea of keeping plugins outside of
> platforms.
> > >>
> > >> What Cordova needs is better "default workflows", e.g.
> > >>
> > >> cordova platform add android
> > >> cordova plugin add chrome-web-dev (install script sets up what you
> > need +
> > >> dependencies)
> > >>
> > >> cordova platform add windows8
> > >> cordova plugin add microsoft.net-dev (install script sets up what you
> > >> need + dependencies)
> > >>
> > >> With this in mind, I think it's a little more obvious how upstream
> > >> distributions could diverge from cordova.
> > >>
> > >> In that sense, I'm -1 to:
> > >> supporting plugin dependencies for platforms
> > >>
> > >>
> > >>
> >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Jesse <pu...@gmail.com>.
More on the concept of rolling into a platform ...
My distinction is that there are some things that every platform should
consider a baseline of browser functionality, and if the OS SDKs do not
provide it out of the box, then we should. Some examples of this :
1. Local XHR, Windows Phone does not support xhr when trying to access a
file:// url, I could have made this a plugin that would only be used on WP,
but I think this functionality should be intrinsic, so now it is.
2. console.log: if you create a brand new iOS cordova project, the
hello-world app gives you some boilerplate code to get started. One thing
that new users may notice is the use of console.log in index.js, however,
they will never see the output. Hooking conosle.log output to go to the
command-line output of a run command, or the output window of visual
studio, or xcode is the minimum functionality, and I personally think it
should be built in. This is probably best discussed in a new thread, as I
know Michal has a different opinion, because of some weinre edge case, but
this is meant to serve more as an example.
What is core?:
Core used to mean everything that we built in, now I think it means
everything that we ship,
>> Does "core" mean that it has the namespace "org.apache.cordova."?
>> Does "core" mean that it is something we will support?
>> Does "core" mean that it is something that applies to multiple platforms?
I think it means all of these things.
Back to the original subject :
I think keyboard makes the most sense in org.apache.cordova.labs, or built
right into the platform, it does not have wide enough reach to be 'core' in
my opinion. Inclusion in the cordova-ios directly is probably a subject to
the following questions :
- how important is it? Can apps live without it?
- is there ever a reason to NOT use this?
- will it ever make sense for other platforms to implement the same APIs?
org.apache.cordova.statusbar
I think statusbar makes sense as a 'core' plugin, because it is implemented
for iOS/Android and WP7/8. Some of the APIs are currently very iOS
specific, but that is a topic for another thread.
@purplecabbage
risingj.com
On Mon, Mar 10, 2014 at 12:05 PM, Tommy-Carlos Williams
<to...@devgeeks.org>wrote:
> +1
>
>
> On 11 Mar 2014, at 5:52 am, Brian LeRoux <b...@brian.io> wrote:
>
> > While I wholeheartedly agree plugins, clean separation of concerns,
> > discreet repos, all have big benefits if every single developer installs
> a
> > plugin on day 1 that is specific to a particular platform I feel that
> might
> > be a good indication the platform should conditionally roll that plugin
> in.
> > I think the statusbar might quality.
> >
> >
> >
> >
> > On Mon, Mar 10, 2014 at 10:30 AM, Jonathan Bond-Caron <
> > jbondc@gdesolutions.com> wrote:
> >
> >> On Mon Mar 10 12:51 PM, Michal Mocny wrote:
> >>>
> >>> I think we can solve that problem using a plethora of better
> >>> alternatives, including
> >>> install scripts (perhaps with a generator
> >>> like yeoman, perhaps my just pasting
> >>> snippets in tutorials), by
> >>> supporting plugin dependencies for platforms, or just by
> >>> hard coding
> >>> a list of default plugins in cordova-cli (we do this in cca for
> >>> example).
> >>> Many alternatives exist.
> >>>
> >>
> >> Kind of agree, I like the idea of keeping plugins outside of platforms.
> >>
> >> What Cordova needs is better "default workflows", e.g.
> >>
> >> cordova platform add android
> >> cordova plugin add chrome-web-dev (install script sets up what you
> need +
> >> dependencies)
> >>
> >> cordova platform add windows8
> >> cordova plugin add microsoft.net-dev (install script sets up what you
> >> need + dependencies)
> >>
> >> With this in mind, I think it's a little more obvious how upstream
> >> distributions could diverge from cordova.
> >>
> >> In that sense, I'm -1 to:
> >> supporting plugin dependencies for platforms
> >>
> >>
> >>
>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Sidney Bofah <si...@neofonie.de>.
+1
On 10 Mar 2014, at 20:05, Tommy-Carlos Williams <to...@devgeeks.org> wrote:
> +1
>
>
> On 11 Mar 2014, at 5:52 am, Brian LeRoux <b...@brian.io> wrote:
>
>> While I wholeheartedly agree plugins, clean separation of concerns,
>> discreet repos, all have big benefits if every single developer installs a
>> plugin on day 1 that is specific to a particular platform I feel that might
>> be a good indication the platform should conditionally roll that plugin in.
>> I think the statusbar might quality.
>>
>>
>>
>>
>> On Mon, Mar 10, 2014 at 10:30 AM, Jonathan Bond-Caron <
>> jbondc@gdesolutions.com> wrote:
>>
>>> On Mon Mar 10 12:51 PM, Michal Mocny wrote:
>>>>
>>>> I think we can solve that problem using a plethora of better
>>>> alternatives, including
>>>> install scripts (perhaps with a generator
>>>> like yeoman, perhaps my just pasting
>>>> snippets in tutorials), by
>>>> supporting plugin dependencies for platforms, or just by
>>>> hard coding
>>>> a list of default plugins in cordova-cli (we do this in cca for
>>>> example).
>>>> Many alternatives exist.
>>>>
>>>
>>> Kind of agree, I like the idea of keeping plugins outside of platforms.
>>>
>>> What Cordova needs is better "default workflows", e.g.
>>>
>>> cordova platform add android
>>> cordova plugin add chrome-web-dev (install script sets up what you need +
>>> dependencies)
>>>
>>> cordova platform add windows8
>>> cordova plugin add microsoft.net-dev (install script sets up what you
>>> need + dependencies)
>>>
>>> With this in mind, I think it's a little more obvious how upstream
>>> distributions could diverge from cordova.
>>>
>>> In that sense, I'm -1 to:
>>> supporting plugin dependencies for platforms
>>>
>>>
>>>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Tommy-Carlos Williams <to...@devgeeks.org>.
+1
On 11 Mar 2014, at 5:52 am, Brian LeRoux <b...@brian.io> wrote:
> While I wholeheartedly agree plugins, clean separation of concerns,
> discreet repos, all have big benefits if every single developer installs a
> plugin on day 1 that is specific to a particular platform I feel that might
> be a good indication the platform should conditionally roll that plugin in.
> I think the statusbar might quality.
>
>
>
>
> On Mon, Mar 10, 2014 at 10:30 AM, Jonathan Bond-Caron <
> jbondc@gdesolutions.com> wrote:
>
>> On Mon Mar 10 12:51 PM, Michal Mocny wrote:
>>>
>>> I think we can solve that problem using a plethora of better
>>> alternatives, including
>>> install scripts (perhaps with a generator
>>> like yeoman, perhaps my just pasting
>>> snippets in tutorials), by
>>> supporting plugin dependencies for platforms, or just by
>>> hard coding
>>> a list of default plugins in cordova-cli (we do this in cca for
>>> example).
>>> Many alternatives exist.
>>>
>>
>> Kind of agree, I like the idea of keeping plugins outside of platforms.
>>
>> What Cordova needs is better "default workflows", e.g.
>>
>> cordova platform add android
>> cordova plugin add chrome-web-dev (install script sets up what you need +
>> dependencies)
>>
>> cordova platform add windows8
>> cordova plugin add microsoft.net-dev (install script sets up what you
>> need + dependencies)
>>
>> With this in mind, I think it's a little more obvious how upstream
>> distributions could diverge from cordova.
>>
>> In that sense, I'm -1 to:
>> supporting plugin dependencies for platforms
>>
>>
>>
RE: [cordova-plugins/statusbar] Publishing as core
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
> Import 'plaforms/android' into Eclipse:
> https://onedrive.live.com/?gologin=1&mkt=en-
> US#cid=295047487FC4F731&id=295047487FC4F731%215602&v=3
>
> Broken... but "cordova run" works... Is using eclipse still a 'core' thing?
> It's a "still want to use an IDE" thing. My preference is a cordova that embraces
> diversity.
>
Related:
https://issues.apache.org/jira/browse/CB-3445
My impression is Cordova gets used in different ways by many, championing certain "flows" could be a path towards stability & better ecosystem.
I think what I'm trying to say is if there's a 'champion' committer for the IDE flow and he or community needs plugins (a,b,c), then that flow & the plugins (a,b,c) should be considered core.
Plugin dependencies rolled into platforms doesn't seem like the right direction.
RE: [cordova-plugins/statusbar] Publishing as core
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Mon Mar 10 02:52 PM, Brian LeRoux wrote:
> While I wholeheartedly agree plugins, clean separation of concerns, discreet
> repos, all have big benefits if every single developer installs a plugin on day 1 that
> is specific to a particular platform I feel that might be a good indication the
> platform should conditionally roll that plugin in.
> I think the statusbar might quality.
>
Good point, IMHO it's more part of a popular 'core' web dev flow:
cordova plugin add org.apache.cordova.web-dev (include statusbar & console.log, others?)
Arguably a CSS fix works too:
http://stackoverflow.com/questions/18886195/ios-7-status-bar-overlapping-ui
Some related frustration:
cordova create bar
cordova platform add android
Import 'plaforms/android' into Eclipse:
https://onedrive.live.com/?gologin=1&mkt=en-US#cid=295047487FC4F731&id=295047487FC4F731%215602&v=3
Broken... but "cordova run" works... Is using eclipse still a 'core' thing?
It's a "still want to use an IDE" thing. My preference is a cordova that embraces diversity.
Back to statusbar, some might prefer native code through xcode / not using the plugin.
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Brian LeRoux <b...@brian.io>.
While I wholeheartedly agree plugins, clean separation of concerns,
discreet repos, all have big benefits if every single developer installs a
plugin on day 1 that is specific to a particular platform I feel that might
be a good indication the platform should conditionally roll that plugin in.
I think the statusbar might quality.
On Mon, Mar 10, 2014 at 10:30 AM, Jonathan Bond-Caron <
jbondc@gdesolutions.com> wrote:
> On Mon Mar 10 12:51 PM, Michal Mocny wrote:
> >
> > I think we can solve that problem using a plethora of better
> > alternatives, including
> > install scripts (perhaps with a generator
> > like yeoman, perhaps my just pasting
> > snippets in tutorials), by
> > supporting plugin dependencies for platforms, or just by
> > hard coding
> > a list of default plugins in cordova-cli (we do this in cca for
> > example).
> > Many alternatives exist.
> >
>
> Kind of agree, I like the idea of keeping plugins outside of platforms.
>
> What Cordova needs is better "default workflows", e.g.
>
> cordova platform add android
> cordova plugin add chrome-web-dev (install script sets up what you need +
> dependencies)
>
> cordova platform add windows8
> cordova plugin add microsoft.net-dev (install script sets up what you
> need + dependencies)
>
> With this in mind, I think it's a little more obvious how upstream
> distributions could diverge from cordova.
>
> In that sense, I'm -1 to:
> supporting plugin dependencies for platforms
>
>
>
RE: [cordova-plugins/statusbar] Publishing as core
Posted by Jonathan Bond-Caron <jb...@gdesolutions.com>.
On Mon Mar 10 12:51 PM, Michal Mocny wrote:
>
> I think we can solve that problem using a plethora of better
> alternatives, including
> install scripts (perhaps with a generator
> like yeoman, perhaps my just pasting
> snippets in tutorials), by
> supporting plugin dependencies for platforms, or just by
> hard coding
> a list of default plugins in cordova-cli (we do this in cca for
> example).
> Many alternatives exist.
>
Kind of agree, I like the idea of keeping plugins outside of platforms.
What Cordova needs is better "default workflows", e.g.
cordova platform add android
cordova plugin add chrome-web-dev (install script sets up what you need + dependencies)
cordova platform add windows8
cordova plugin add microsoft.net-dev (install script sets up what you need + dependencies)
With this in mind, I think it's a little more obvious how upstream distributions could diverge from cordova.
In that sense, I'm -1 to:
supporting plugin dependencies for platforms
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Michal Mocny <mm...@chromium.org>.
Whats the benefit of rolling plugins into a platform? The only one I can
see is "installed by default" which means better "out of box" experience
for new users.
I think we can solve that problem using a plethora of better alternatives,
including install scripts (perhaps with a generator like yeoman, perhaps my
just pasting snippets in tutorials), by supporting plugin dependencies for
platforms, or just by hard coding a list of default plugins in cordova-cli
(we do this in cca for example). Many alternatives exist.
I'm not sure if we need to iterate the list of benefits in leaving features
implemented inside plugins, but I think its almost entirely upside to do so.
-Michal
On Mon, Mar 10, 2014 at 11:45 AM, Brian LeRoux <b...@brian.io> wrote:
> I like it. Statusbar is considered core by the community. That said, should
> it be rolled into the platform as a feature?
>
>
> On Mon, Mar 10, 2014 at 7:39 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > What does core mean?
> >
> > Does "core" mean that it has the namespace "org.apache.cordova."?
> > Does "core" mean that it is something we will support?
> > Does "core" mean that it is something that applies to multiple platforms?
> >
> >
> > I would like "core" to be the first two. And by "we", I mean at least one
> > committer. That's generally how platforms have worked (if no committers
> is
> > interested in maintaining them, then they don't get worked on. Otherwise,
> > they do).
> >
> > I do also like the idea of a "org.apache.cordova.labs" namespace. We
> could
> > use it to mean that it's something we are thinking about being "core" in
> > the future, but it's at risk of changing (e.g. API fluctuation), or of us
> > deciding it's not actually worth our time to support.
> >
> > I would put statusbar as "core" given the stated importance of it so far,
> > and given that multiple people are willing to work on it.
> >
> > I would put keyboard as "labs" due to the current quality of it (serious
> > iOS7 bugs, unsolved dead-zone when removing accessory).
> >
> >
> >
> >
> >
> >
> > On Fri, Mar 7, 2014 at 7:31 PM, purplecabbage <purplecabbage@gmail.com
> > >wrote:
> >
> > > StatusBar wp7+8 is mostly done. Just testing some stuff now.
> > >
> > > Sent from my iPhone
> > >
> > > > On Mar 7, 2014, at 3:30 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > > Technically there are two platforms right now. Android has minimal
> > > support,
> > > > and Jesse wants to do WP8 (again minimal), so thats another.
> > > >
> > > >
> > > >> On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI <an...@gmail.com>
> > > wrote:
> > > >>
> > > >> +1 for labs. it doesn't really make sense to have them in core if
> they
> > > only
> > > >> support one platform.
> > > >>
> > > >>
> > > >>> On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wj...@gmail.com>
> > > wrote:
> > > >>>
> > > >>> Similar to keyboard plugin, I like the idea of letting this bake in
> > > labs
> > > >>> for now and moving them into core if we see multiple platforms
> start
> > > >>> needing a similar API. So (a) and (c) for me.
> > > >>>
> > > >>> I would add that the iOS 6/7 specific code may not make sense as
> > > "core".
> > > >>>
> > > >>> -James Jong
> > > >>>
> > > >>>> On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com>
> wrote:
> > > >>>>
> > > >>>> I have created a task in JIRA for all the statusbar related
> > > discussion.
> > > >>> [1]
> > > >>>> There are numerous inconsistencies we need to address here.
> > > >>>>
> > > >>>> [1] https://issues.apache.org/jira/browse/CB-6177
> > > >>>>
> > > >>>> @purplecabbage
> > > >>>> risingj.com
> > > >>>>
> > > >>>>
> > > >>>>> On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com>
> wrote:
> > > >>>>>
> > > >>>>> Some background on the statusbar plugin.
> > > >>>>>
> > > >>>>> This was conceived because of iOS 7 where the statusbar overlays
> > the
> > > >>>>> webview, and a lot of people didn't like their UI changing
> > especially
> > > >> if
> > > >>>>> they still support iOS 6. That is the primary purpose of this
> > plugin,
> > > >>> but
> > > >>>>> there are other features in there as well. In the last few weeks,
> > > >> there
> > > >>> was
> > > >>>>> a pull request (now integrated) for StatusBar.hide and
> > StatusBar.show
> > > >>> for
> > > >>>>> Android as well.
> > > >>>>>
> > > >>>>> The issues related to the statusbar are under the label
> > > >>> "statusbar-plugin"
> > > >>>>> in JIRA, and there are currently 11 open issues. There are pull
> > > >> requests
> > > >>>>> for it from the PhoneGap Build team that I am waiting to
> integrate
> > --
> > > >>> not
> > > >>>>> until we get this namespace stuff sorted out.
> > > >>>>>
> > > >>>>> I am not opposed to it being under the "labs" namespace. After
> > > talking
> > > >>> to
> > > >>>>> the Adobe team, we could also host the plugin under the PhoneGap
> > > >> Github
> > > >>>>> org, but I'd rather use that as a last resort.
> > > >>>>>
> > > >>>>>
> > > >>>>> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <
> mmocny@chromium.org
> > >
> > > >>> wrote:
> > > >>>>>
> > > >>>>>> (a) Yes.
> > > >>>>>> (b) No -- some organizations (Adobe) don't like this, and we
> > respect
> > > >>>>> that.
> > > >>>>>> We also want to point users at these plugins, so its good to
> have
> > > >>>>>> developers protected by Apache.
> > > >>>>>> (c) Sure -- so long as labs is clearly separate, and we leave
> them
> > > >> out
> > > >>> of
> > > >>>>>> blogs / plugin release notes, and we don't impact the rate of
> > > >> releases
> > > >>>>>> (i.e. we don't force devs to test the labs plugins, just verify
> > the
> > > >>>>>> signatures is enough).
> > > >>>>>> (d) I think the "guardian" of these labs plugins should be free
> to
> > > >>>>> publish.
> > > >>>>>> There is no reason they are lower quality than anything else.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Separate issue: is statusbar ready for Core? I think we should
> > > leave
> > > >>> it
> > > >>>>> in
> > > >>>>>> labs for a little bit, have at least a few eyes audit the API
> and
> > > >>>>>> investigate if there is any other similar work in the field
> before
> > > we
> > > >>>>> make
> > > >>>>>> users depend on this, but that it should move to core
> eventually.
> > > >>>>>>
> > > >>>>>> -Michal
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org>
> > > wrote:
> > > >>>>>>>
> > > >>>>>>> statusbar is already published org.apache.cordova.statusbar.
> > > >>>>>>>
> > > >>>>>>> And... Since these plugins are somewhat experimental and we're
> > > >>> starting
> > > >>>>>> the
> > > >>>>>>> process of voting and publishing plugins to dist/, I wonder:
> > > >>>>>>>
> > > >>>>>>> a) Should we change the ID of these plugins to, say
> > > >>>>>>> "org.apache.cordova.labs"
> > > >>>>>>> b) Should we move these plugins to github and have them not
> under
> > > >>>>> apache
> > > >>>>>>> for now, e.g.: com.shazron.statusbar
> > > >>>>>>> c) Should we just add them to the plugin release process.
> > > >>>>>>> d) Should we just never publish them to the registry and have
> > > people
> > > >>>>> use
> > > >>>>>>> them via git url.
> > > >>
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Brian LeRoux <b...@brian.io>.
I like it. Statusbar is considered core by the community. That said, should
it be rolled into the platform as a feature?
On Mon, Mar 10, 2014 at 7:39 AM, Andrew Grieve <ag...@chromium.org> wrote:
> What does core mean?
>
> Does "core" mean that it has the namespace "org.apache.cordova."?
> Does "core" mean that it is something we will support?
> Does "core" mean that it is something that applies to multiple platforms?
>
>
> I would like "core" to be the first two. And by "we", I mean at least one
> committer. That's generally how platforms have worked (if no committers is
> interested in maintaining them, then they don't get worked on. Otherwise,
> they do).
>
> I do also like the idea of a "org.apache.cordova.labs" namespace. We could
> use it to mean that it's something we are thinking about being "core" in
> the future, but it's at risk of changing (e.g. API fluctuation), or of us
> deciding it's not actually worth our time to support.
>
> I would put statusbar as "core" given the stated importance of it so far,
> and given that multiple people are willing to work on it.
>
> I would put keyboard as "labs" due to the current quality of it (serious
> iOS7 bugs, unsolved dead-zone when removing accessory).
>
>
>
>
>
>
> On Fri, Mar 7, 2014 at 7:31 PM, purplecabbage <purplecabbage@gmail.com
> >wrote:
>
> > StatusBar wp7+8 is mostly done. Just testing some stuff now.
> >
> > Sent from my iPhone
> >
> > > On Mar 7, 2014, at 3:30 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > > Technically there are two platforms right now. Android has minimal
> > support,
> > > and Jesse wants to do WP8 (again minimal), so thats another.
> > >
> > >
> > >> On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI <an...@gmail.com>
> > wrote:
> > >>
> > >> +1 for labs. it doesn't really make sense to have them in core if they
> > only
> > >> support one platform.
> > >>
> > >>
> > >>> On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wj...@gmail.com>
> > wrote:
> > >>>
> > >>> Similar to keyboard plugin, I like the idea of letting this bake in
> > labs
> > >>> for now and moving them into core if we see multiple platforms start
> > >>> needing a similar API. So (a) and (c) for me.
> > >>>
> > >>> I would add that the iOS 6/7 specific code may not make sense as
> > "core".
> > >>>
> > >>> -James Jong
> > >>>
> > >>>> On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com> wrote:
> > >>>>
> > >>>> I have created a task in JIRA for all the statusbar related
> > discussion.
> > >>> [1]
> > >>>> There are numerous inconsistencies we need to address here.
> > >>>>
> > >>>> [1] https://issues.apache.org/jira/browse/CB-6177
> > >>>>
> > >>>> @purplecabbage
> > >>>> risingj.com
> > >>>>
> > >>>>
> > >>>>> On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
> > >>>>>
> > >>>>> Some background on the statusbar plugin.
> > >>>>>
> > >>>>> This was conceived because of iOS 7 where the statusbar overlays
> the
> > >>>>> webview, and a lot of people didn't like their UI changing
> especially
> > >> if
> > >>>>> they still support iOS 6. That is the primary purpose of this
> plugin,
> > >>> but
> > >>>>> there are other features in there as well. In the last few weeks,
> > >> there
> > >>> was
> > >>>>> a pull request (now integrated) for StatusBar.hide and
> StatusBar.show
> > >>> for
> > >>>>> Android as well.
> > >>>>>
> > >>>>> The issues related to the statusbar are under the label
> > >>> "statusbar-plugin"
> > >>>>> in JIRA, and there are currently 11 open issues. There are pull
> > >> requests
> > >>>>> for it from the PhoneGap Build team that I am waiting to integrate
> --
> > >>> not
> > >>>>> until we get this namespace stuff sorted out.
> > >>>>>
> > >>>>> I am not opposed to it being under the "labs" namespace. After
> > talking
> > >>> to
> > >>>>> the Adobe team, we could also host the plugin under the PhoneGap
> > >> Github
> > >>>>> org, but I'd rather use that as a last resort.
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mmocny@chromium.org
> >
> > >>> wrote:
> > >>>>>
> > >>>>>> (a) Yes.
> > >>>>>> (b) No -- some organizations (Adobe) don't like this, and we
> respect
> > >>>>> that.
> > >>>>>> We also want to point users at these plugins, so its good to have
> > >>>>>> developers protected by Apache.
> > >>>>>> (c) Sure -- so long as labs is clearly separate, and we leave them
> > >> out
> > >>> of
> > >>>>>> blogs / plugin release notes, and we don't impact the rate of
> > >> releases
> > >>>>>> (i.e. we don't force devs to test the labs plugins, just verify
> the
> > >>>>>> signatures is enough).
> > >>>>>> (d) I think the "guardian" of these labs plugins should be free to
> > >>>>> publish.
> > >>>>>> There is no reason they are lower quality than anything else.
> > >>>>>>
> > >>>>>>
> > >>>>>> Separate issue: is statusbar ready for Core? I think we should
> > leave
> > >>> it
> > >>>>> in
> > >>>>>> labs for a little bit, have at least a few eyes audit the API and
> > >>>>>> investigate if there is any other similar work in the field before
> > we
> > >>>>> make
> > >>>>>> users depend on this, but that it should move to core eventually.
> > >>>>>>
> > >>>>>> -Michal
> > >>>>>>
> > >>>>>>
> > >>>>>>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org>
> > wrote:
> > >>>>>>>
> > >>>>>>> statusbar is already published org.apache.cordova.statusbar.
> > >>>>>>>
> > >>>>>>> And... Since these plugins are somewhat experimental and we're
> > >>> starting
> > >>>>>> the
> > >>>>>>> process of voting and publishing plugins to dist/, I wonder:
> > >>>>>>>
> > >>>>>>> a) Should we change the ID of these plugins to, say
> > >>>>>>> "org.apache.cordova.labs"
> > >>>>>>> b) Should we move these plugins to github and have them not under
> > >>>>> apache
> > >>>>>>> for now, e.g.: com.shazron.statusbar
> > >>>>>>> c) Should we just add them to the plugin release process.
> > >>>>>>> d) Should we just never publish them to the registry and have
> > people
> > >>>>> use
> > >>>>>>> them via git url.
> > >>
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Andrew Grieve <ag...@chromium.org>.
What does core mean?
Does "core" mean that it has the namespace "org.apache.cordova."?
Does "core" mean that it is something we will support?
Does "core" mean that it is something that applies to multiple platforms?
I would like "core" to be the first two. And by "we", I mean at least one
committer. That's generally how platforms have worked (if no committers is
interested in maintaining them, then they don't get worked on. Otherwise,
they do).
I do also like the idea of a "org.apache.cordova.labs" namespace. We could
use it to mean that it's something we are thinking about being "core" in
the future, but it's at risk of changing (e.g. API fluctuation), or of us
deciding it's not actually worth our time to support.
I would put statusbar as "core" given the stated importance of it so far,
and given that multiple people are willing to work on it.
I would put keyboard as "labs" due to the current quality of it (serious
iOS7 bugs, unsolved dead-zone when removing accessory).
On Fri, Mar 7, 2014 at 7:31 PM, purplecabbage <pu...@gmail.com>wrote:
> StatusBar wp7+8 is mostly done. Just testing some stuff now.
>
> Sent from my iPhone
>
> > On Mar 7, 2014, at 3:30 PM, Shazron <sh...@gmail.com> wrote:
> >
> > Technically there are two platforms right now. Android has minimal
> support,
> > and Jesse wants to do WP8 (again minimal), so thats another.
> >
> >
> >> On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI <an...@gmail.com>
> wrote:
> >>
> >> +1 for labs. it doesn't really make sense to have them in core if they
> only
> >> support one platform.
> >>
> >>
> >>> On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wj...@gmail.com>
> wrote:
> >>>
> >>> Similar to keyboard plugin, I like the idea of letting this bake in
> labs
> >>> for now and moving them into core if we see multiple platforms start
> >>> needing a similar API. So (a) and (c) for me.
> >>>
> >>> I would add that the iOS 6/7 specific code may not make sense as
> "core".
> >>>
> >>> -James Jong
> >>>
> >>>> On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com> wrote:
> >>>>
> >>>> I have created a task in JIRA for all the statusbar related
> discussion.
> >>> [1]
> >>>> There are numerous inconsistencies we need to address here.
> >>>>
> >>>> [1] https://issues.apache.org/jira/browse/CB-6177
> >>>>
> >>>> @purplecabbage
> >>>> risingj.com
> >>>>
> >>>>
> >>>>> On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
> >>>>>
> >>>>> Some background on the statusbar plugin.
> >>>>>
> >>>>> This was conceived because of iOS 7 where the statusbar overlays the
> >>>>> webview, and a lot of people didn't like their UI changing especially
> >> if
> >>>>> they still support iOS 6. That is the primary purpose of this plugin,
> >>> but
> >>>>> there are other features in there as well. In the last few weeks,
> >> there
> >>> was
> >>>>> a pull request (now integrated) for StatusBar.hide and StatusBar.show
> >>> for
> >>>>> Android as well.
> >>>>>
> >>>>> The issues related to the statusbar are under the label
> >>> "statusbar-plugin"
> >>>>> in JIRA, and there are currently 11 open issues. There are pull
> >> requests
> >>>>> for it from the PhoneGap Build team that I am waiting to integrate --
> >>> not
> >>>>> until we get this namespace stuff sorted out.
> >>>>>
> >>>>> I am not opposed to it being under the "labs" namespace. After
> talking
> >>> to
> >>>>> the Adobe team, we could also host the plugin under the PhoneGap
> >> Github
> >>>>> org, but I'd rather use that as a last resort.
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org>
> >>> wrote:
> >>>>>
> >>>>>> (a) Yes.
> >>>>>> (b) No -- some organizations (Adobe) don't like this, and we respect
> >>>>> that.
> >>>>>> We also want to point users at these plugins, so its good to have
> >>>>>> developers protected by Apache.
> >>>>>> (c) Sure -- so long as labs is clearly separate, and we leave them
> >> out
> >>> of
> >>>>>> blogs / plugin release notes, and we don't impact the rate of
> >> releases
> >>>>>> (i.e. we don't force devs to test the labs plugins, just verify the
> >>>>>> signatures is enough).
> >>>>>> (d) I think the "guardian" of these labs plugins should be free to
> >>>>> publish.
> >>>>>> There is no reason they are lower quality than anything else.
> >>>>>>
> >>>>>>
> >>>>>> Separate issue: is statusbar ready for Core? I think we should
> leave
> >>> it
> >>>>> in
> >>>>>> labs for a little bit, have at least a few eyes audit the API and
> >>>>>> investigate if there is any other similar work in the field before
> we
> >>>>> make
> >>>>>> users depend on this, but that it should move to core eventually.
> >>>>>>
> >>>>>> -Michal
> >>>>>>
> >>>>>>
> >>>>>>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org>
> wrote:
> >>>>>>>
> >>>>>>> statusbar is already published org.apache.cordova.statusbar.
> >>>>>>>
> >>>>>>> And... Since these plugins are somewhat experimental and we're
> >>> starting
> >>>>>> the
> >>>>>>> process of voting and publishing plugins to dist/, I wonder:
> >>>>>>>
> >>>>>>> a) Should we change the ID of these plugins to, say
> >>>>>>> "org.apache.cordova.labs"
> >>>>>>> b) Should we move these plugins to github and have them not under
> >>>>> apache
> >>>>>>> for now, e.g.: com.shazron.statusbar
> >>>>>>> c) Should we just add them to the plugin release process.
> >>>>>>> d) Should we just never publish them to the registry and have
> people
> >>>>> use
> >>>>>>> them via git url.
> >>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by purplecabbage <pu...@gmail.com>.
StatusBar wp7+8 is mostly done. Just testing some stuff now.
Sent from my iPhone
> On Mar 7, 2014, at 3:30 PM, Shazron <sh...@gmail.com> wrote:
>
> Technically there are two platforms right now. Android has minimal support,
> and Jesse wants to do WP8 (again minimal), so thats another.
>
>
>> On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI <an...@gmail.com> wrote:
>>
>> +1 for labs. it doesn't really make sense to have them in core if they only
>> support one platform.
>>
>>
>>> On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wj...@gmail.com> wrote:
>>>
>>> Similar to keyboard plugin, I like the idea of letting this bake in labs
>>> for now and moving them into core if we see multiple platforms start
>>> needing a similar API. So (a) and (c) for me.
>>>
>>> I would add that the iOS 6/7 specific code may not make sense as "core".
>>>
>>> -James Jong
>>>
>>>> On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com> wrote:
>>>>
>>>> I have created a task in JIRA for all the statusbar related discussion.
>>> [1]
>>>> There are numerous inconsistencies we need to address here.
>>>>
>>>> [1] https://issues.apache.org/jira/browse/CB-6177
>>>>
>>>> @purplecabbage
>>>> risingj.com
>>>>
>>>>
>>>>> On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
>>>>>
>>>>> Some background on the statusbar plugin.
>>>>>
>>>>> This was conceived because of iOS 7 where the statusbar overlays the
>>>>> webview, and a lot of people didn't like their UI changing especially
>> if
>>>>> they still support iOS 6. That is the primary purpose of this plugin,
>>> but
>>>>> there are other features in there as well. In the last few weeks,
>> there
>>> was
>>>>> a pull request (now integrated) for StatusBar.hide and StatusBar.show
>>> for
>>>>> Android as well.
>>>>>
>>>>> The issues related to the statusbar are under the label
>>> "statusbar-plugin"
>>>>> in JIRA, and there are currently 11 open issues. There are pull
>> requests
>>>>> for it from the PhoneGap Build team that I am waiting to integrate --
>>> not
>>>>> until we get this namespace stuff sorted out.
>>>>>
>>>>> I am not opposed to it being under the "labs" namespace. After talking
>>> to
>>>>> the Adobe team, we could also host the plugin under the PhoneGap
>> Github
>>>>> org, but I'd rather use that as a last resort.
>>>>>
>>>>>
>>>>> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>>>>
>>>>>> (a) Yes.
>>>>>> (b) No -- some organizations (Adobe) don't like this, and we respect
>>>>> that.
>>>>>> We also want to point users at these plugins, so its good to have
>>>>>> developers protected by Apache.
>>>>>> (c) Sure -- so long as labs is clearly separate, and we leave them
>> out
>>> of
>>>>>> blogs / plugin release notes, and we don't impact the rate of
>> releases
>>>>>> (i.e. we don't force devs to test the labs plugins, just verify the
>>>>>> signatures is enough).
>>>>>> (d) I think the "guardian" of these labs plugins should be free to
>>>>> publish.
>>>>>> There is no reason they are lower quality than anything else.
>>>>>>
>>>>>>
>>>>>> Separate issue: is statusbar ready for Core? I think we should leave
>>> it
>>>>> in
>>>>>> labs for a little bit, have at least a few eyes audit the API and
>>>>>> investigate if there is any other similar work in the field before we
>>>>> make
>>>>>> users depend on this, but that it should move to core eventually.
>>>>>>
>>>>>> -Michal
>>>>>>
>>>>>>
>>>>>>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org> wrote:
>>>>>>>
>>>>>>> statusbar is already published org.apache.cordova.statusbar.
>>>>>>>
>>>>>>> And... Since these plugins are somewhat experimental and we're
>>> starting
>>>>>> the
>>>>>>> process of voting and publishing plugins to dist/, I wonder:
>>>>>>>
>>>>>>> a) Should we change the ID of these plugins to, say
>>>>>>> "org.apache.cordova.labs"
>>>>>>> b) Should we move these plugins to github and have them not under
>>>>> apache
>>>>>>> for now, e.g.: com.shazron.statusbar
>>>>>>> c) Should we just add them to the plugin release process.
>>>>>>> d) Should we just never publish them to the registry and have people
>>>>> use
>>>>>>> them via git url.
>>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Tommy Williams <to...@devgeeks.org>.
Well, as much as I'd like the faster iteration of plugins, I think from a
user perspective that these two bits of functionality are pretty important.
Users need them. iOS apps without the status bar plugin are fairly limited
in how they can be styled, etc. The default is dark text, so only a light
navbar is possible out of the box without it.
The keyboard plugin is also pretty serious. Any forms stuff in iOS has to
be above the keyboard height or it gets pretty flakey. It's a pretty bad
experience.
I am worried we are thinking about software engineering organization and
not about making cordova a viable platform for most developers.
- tommy
On 08/03/2014 10:31 am, "Shazron" <sh...@gmail.com> wrote:
> Technically there are two platforms right now. Android has minimal support,
> and Jesse wants to do WP8 (again minimal), so thats another.
>
>
> On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI <an...@gmail.com> wrote:
>
> > +1 for labs. it doesn't really make sense to have them in core if they
> only
> > support one platform.
> >
> >
> > On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wj...@gmail.com> wrote:
> >
> > > Similar to keyboard plugin, I like the idea of letting this bake in
> labs
> > > for now and moving them into core if we see multiple platforms start
> > > needing a similar API. So (a) and (c) for me.
> > >
> > > I would add that the iOS 6/7 specific code may not make sense as
> "core".
> > >
> > > -James Jong
> > >
> > > On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com> wrote:
> > >
> > > > I have created a task in JIRA for all the statusbar related
> discussion.
> > > [1]
> > > > There are numerous inconsistencies we need to address here.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CB-6177
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
> > > >
> > > >> Some background on the statusbar plugin.
> > > >>
> > > >> This was conceived because of iOS 7 where the statusbar overlays the
> > > >> webview, and a lot of people didn't like their UI changing
> especially
> > if
> > > >> they still support iOS 6. That is the primary purpose of this
> plugin,
> > > but
> > > >> there are other features in there as well. In the last few weeks,
> > there
> > > was
> > > >> a pull request (now integrated) for StatusBar.hide and
> StatusBar.show
> > > for
> > > >> Android as well.
> > > >>
> > > >> The issues related to the statusbar are under the label
> > > "statusbar-plugin"
> > > >> in JIRA, and there are currently 11 open issues. There are pull
> > requests
> > > >> for it from the PhoneGap Build team that I am waiting to integrate
> --
> > > not
> > > >> until we get this namespace stuff sorted out.
> > > >>
> > > >> I am not opposed to it being under the "labs" namespace. After
> talking
> > > to
> > > >> the Adobe team, we could also host the plugin under the PhoneGap
> > Github
> > > >> org, but I'd rather use that as a last resort.
> > > >>
> > > >>
> > > >> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >>
> > > >>> (a) Yes.
> > > >>> (b) No -- some organizations (Adobe) don't like this, and we
> respect
> > > >> that.
> > > >>> We also want to point users at these plugins, so its good to have
> > > >>> developers protected by Apache.
> > > >>> (c) Sure -- so long as labs is clearly separate, and we leave them
> > out
> > > of
> > > >>> blogs / plugin release notes, and we don't impact the rate of
> > releases
> > > >>> (i.e. we don't force devs to test the labs plugins, just verify the
> > > >>> signatures is enough).
> > > >>> (d) I think the "guardian" of these labs plugins should be free to
> > > >> publish.
> > > >>> There is no reason they are lower quality than anything else.
> > > >>>
> > > >>>
> > > >>> Separate issue: is statusbar ready for Core? I think we should
> leave
> > > it
> > > >> in
> > > >>> labs for a little bit, have at least a few eyes audit the API and
> > > >>> investigate if there is any other similar work in the field before
> we
> > > >> make
> > > >>> users depend on this, but that it should move to core eventually.
> > > >>>
> > > >>> -Michal
> > > >>>
> > > >>>
> > > >>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org>
> wrote:
> > > >>>
> > > >>>> statusbar is already published org.apache.cordova.statusbar.
> > > >>>>
> > > >>>> And... Since these plugins are somewhat experimental and we're
> > > starting
> > > >>> the
> > > >>>> process of voting and publishing plugins to dist/, I wonder:
> > > >>>>
> > > >>>> a) Should we change the ID of these plugins to, say
> > > >>>> "org.apache.cordova.labs"
> > > >>>> b) Should we move these plugins to github and have them not under
> > > >> apache
> > > >>>> for now, e.g.: com.shazron.statusbar
> > > >>>> c) Should we just add them to the plugin release process.
> > > >>>> d) Should we just never publish them to the registry and have
> people
> > > >> use
> > > >>>> them via git url.
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Shazron <sh...@gmail.com>.
Technically there are two platforms right now. Android has minimal support,
and Jesse wants to do WP8 (again minimal), so thats another.
On Fri, Mar 7, 2014 at 3:23 PM, Anis KADRI <an...@gmail.com> wrote:
> +1 for labs. it doesn't really make sense to have them in core if they only
> support one platform.
>
>
> On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wj...@gmail.com> wrote:
>
> > Similar to keyboard plugin, I like the idea of letting this bake in labs
> > for now and moving them into core if we see multiple platforms start
> > needing a similar API. So (a) and (c) for me.
> >
> > I would add that the iOS 6/7 specific code may not make sense as "core".
> >
> > -James Jong
> >
> > On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com> wrote:
> >
> > > I have created a task in JIRA for all the statusbar related discussion.
> > [1]
> > > There are numerous inconsistencies we need to address here.
> > >
> > > [1] https://issues.apache.org/jira/browse/CB-6177
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
> > >
> > >> Some background on the statusbar plugin.
> > >>
> > >> This was conceived because of iOS 7 where the statusbar overlays the
> > >> webview, and a lot of people didn't like their UI changing especially
> if
> > >> they still support iOS 6. That is the primary purpose of this plugin,
> > but
> > >> there are other features in there as well. In the last few weeks,
> there
> > was
> > >> a pull request (now integrated) for StatusBar.hide and StatusBar.show
> > for
> > >> Android as well.
> > >>
> > >> The issues related to the statusbar are under the label
> > "statusbar-plugin"
> > >> in JIRA, and there are currently 11 open issues. There are pull
> requests
> > >> for it from the PhoneGap Build team that I am waiting to integrate --
> > not
> > >> until we get this namespace stuff sorted out.
> > >>
> > >> I am not opposed to it being under the "labs" namespace. After talking
> > to
> > >> the Adobe team, we could also host the plugin under the PhoneGap
> Github
> > >> org, but I'd rather use that as a last resort.
> > >>
> > >>
> > >> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >>
> > >>> (a) Yes.
> > >>> (b) No -- some organizations (Adobe) don't like this, and we respect
> > >> that.
> > >>> We also want to point users at these plugins, so its good to have
> > >>> developers protected by Apache.
> > >>> (c) Sure -- so long as labs is clearly separate, and we leave them
> out
> > of
> > >>> blogs / plugin release notes, and we don't impact the rate of
> releases
> > >>> (i.e. we don't force devs to test the labs plugins, just verify the
> > >>> signatures is enough).
> > >>> (d) I think the "guardian" of these labs plugins should be free to
> > >> publish.
> > >>> There is no reason they are lower quality than anything else.
> > >>>
> > >>>
> > >>> Separate issue: is statusbar ready for Core? I think we should leave
> > it
> > >> in
> > >>> labs for a little bit, have at least a few eyes audit the API and
> > >>> investigate if there is any other similar work in the field before we
> > >> make
> > >>> users depend on this, but that it should move to core eventually.
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org> wrote:
> > >>>
> > >>>> statusbar is already published org.apache.cordova.statusbar.
> > >>>>
> > >>>> And... Since these plugins are somewhat experimental and we're
> > starting
> > >>> the
> > >>>> process of voting and publishing plugins to dist/, I wonder:
> > >>>>
> > >>>> a) Should we change the ID of these plugins to, say
> > >>>> "org.apache.cordova.labs"
> > >>>> b) Should we move these plugins to github and have them not under
> > >> apache
> > >>>> for now, e.g.: com.shazron.statusbar
> > >>>> c) Should we just add them to the plugin release process.
> > >>>> d) Should we just never publish them to the registry and have people
> > >> use
> > >>>> them via git url.
> > >>>>
> > >>>
> > >>
> >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Anis KADRI <an...@gmail.com>.
+1 for labs. it doesn't really make sense to have them in core if they only
support one platform.
On Thu, Mar 6, 2014 at 8:47 AM, James Jong <wj...@gmail.com> wrote:
> Similar to keyboard plugin, I like the idea of letting this bake in labs
> for now and moving them into core if we see multiple platforms start
> needing a similar API. So (a) and (c) for me.
>
> I would add that the iOS 6/7 specific code may not make sense as "core".
>
> -James Jong
>
> On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com> wrote:
>
> > I have created a task in JIRA for all the statusbar related discussion.
> [1]
> > There are numerous inconsistencies we need to address here.
> >
> > [1] https://issues.apache.org/jira/browse/CB-6177
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
> >
> >> Some background on the statusbar plugin.
> >>
> >> This was conceived because of iOS 7 where the statusbar overlays the
> >> webview, and a lot of people didn't like their UI changing especially if
> >> they still support iOS 6. That is the primary purpose of this plugin,
> but
> >> there are other features in there as well. In the last few weeks, there
> was
> >> a pull request (now integrated) for StatusBar.hide and StatusBar.show
> for
> >> Android as well.
> >>
> >> The issues related to the statusbar are under the label
> "statusbar-plugin"
> >> in JIRA, and there are currently 11 open issues. There are pull requests
> >> for it from the PhoneGap Build team that I am waiting to integrate --
> not
> >> until we get this namespace stuff sorted out.
> >>
> >> I am not opposed to it being under the "labs" namespace. After talking
> to
> >> the Adobe team, we could also host the plugin under the PhoneGap Github
> >> org, but I'd rather use that as a last resort.
> >>
> >>
> >> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >>
> >>> (a) Yes.
> >>> (b) No -- some organizations (Adobe) don't like this, and we respect
> >> that.
> >>> We also want to point users at these plugins, so its good to have
> >>> developers protected by Apache.
> >>> (c) Sure -- so long as labs is clearly separate, and we leave them out
> of
> >>> blogs / plugin release notes, and we don't impact the rate of releases
> >>> (i.e. we don't force devs to test the labs plugins, just verify the
> >>> signatures is enough).
> >>> (d) I think the "guardian" of these labs plugins should be free to
> >> publish.
> >>> There is no reason they are lower quality than anything else.
> >>>
> >>>
> >>> Separate issue: is statusbar ready for Core? I think we should leave
> it
> >> in
> >>> labs for a little bit, have at least a few eyes audit the API and
> >>> investigate if there is any other similar work in the field before we
> >> make
> >>> users depend on this, but that it should move to core eventually.
> >>>
> >>> -Michal
> >>>
> >>>
> >>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org> wrote:
> >>>
> >>>> statusbar is already published org.apache.cordova.statusbar.
> >>>>
> >>>> And... Since these plugins are somewhat experimental and we're
> starting
> >>> the
> >>>> process of voting and publishing plugins to dist/, I wonder:
> >>>>
> >>>> a) Should we change the ID of these plugins to, say
> >>>> "org.apache.cordova.labs"
> >>>> b) Should we move these plugins to github and have them not under
> >> apache
> >>>> for now, e.g.: com.shazron.statusbar
> >>>> c) Should we just add them to the plugin release process.
> >>>> d) Should we just never publish them to the registry and have people
> >> use
> >>>> them via git url.
> >>>>
> >>>
> >>
>
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by James Jong <wj...@gmail.com>.
Similar to keyboard plugin, I like the idea of letting this bake in labs for now and moving them into core if we see multiple platforms start needing a similar API. So (a) and (c) for me.
I would add that the iOS 6/7 specific code may not make sense as "core”.
-James Jong
On Mar 5, 2014, at 9:10 PM, Jesse <pu...@gmail.com> wrote:
> I have created a task in JIRA for all the statusbar related discussion. [1]
> There are numerous inconsistencies we need to address here.
>
> [1] https://issues.apache.org/jira/browse/CB-6177
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
>
>> Some background on the statusbar plugin.
>>
>> This was conceived because of iOS 7 where the statusbar overlays the
>> webview, and a lot of people didn't like their UI changing especially if
>> they still support iOS 6. That is the primary purpose of this plugin, but
>> there are other features in there as well. In the last few weeks, there was
>> a pull request (now integrated) for StatusBar.hide and StatusBar.show for
>> Android as well.
>>
>> The issues related to the statusbar are under the label "statusbar-plugin"
>> in JIRA, and there are currently 11 open issues. There are pull requests
>> for it from the PhoneGap Build team that I am waiting to integrate -- not
>> until we get this namespace stuff sorted out.
>>
>> I am not opposed to it being under the "labs" namespace. After talking to
>> the Adobe team, we could also host the plugin under the PhoneGap Github
>> org, but I'd rather use that as a last resort.
>>
>>
>> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org> wrote:
>>
>>> (a) Yes.
>>> (b) No -- some organizations (Adobe) don't like this, and we respect
>> that.
>>> We also want to point users at these plugins, so its good to have
>>> developers protected by Apache.
>>> (c) Sure -- so long as labs is clearly separate, and we leave them out of
>>> blogs / plugin release notes, and we don't impact the rate of releases
>>> (i.e. we don't force devs to test the labs plugins, just verify the
>>> signatures is enough).
>>> (d) I think the "guardian" of these labs plugins should be free to
>> publish.
>>> There is no reason they are lower quality than anything else.
>>>
>>>
>>> Separate issue: is statusbar ready for Core? I think we should leave it
>> in
>>> labs for a little bit, have at least a few eyes audit the API and
>>> investigate if there is any other similar work in the field before we
>> make
>>> users depend on this, but that it should move to core eventually.
>>>
>>> -Michal
>>>
>>>
>>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org> wrote:
>>>
>>>> statusbar is already published org.apache.cordova.statusbar.
>>>>
>>>> And... Since these plugins are somewhat experimental and we're starting
>>> the
>>>> process of voting and publishing plugins to dist/, I wonder:
>>>>
>>>> a) Should we change the ID of these plugins to, say
>>>> "org.apache.cordova.labs"
>>>> b) Should we move these plugins to github and have them not under
>> apache
>>>> for now, e.g.: com.shazron.statusbar
>>>> c) Should we just add them to the plugin release process.
>>>> d) Should we just never publish them to the registry and have people
>> use
>>>> them via git url.
>>>>
>>>
>>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Jesse <pu...@gmail.com>.
I have created a task in JIRA for all the statusbar related discussion. [1]
There are numerous inconsistencies we need to address here.
[1] https://issues.apache.org/jira/browse/CB-6177
@purplecabbage
risingj.com
On Wed, Mar 5, 2014 at 5:15 PM, Shazron <sh...@gmail.com> wrote:
> Some background on the statusbar plugin.
>
> This was conceived because of iOS 7 where the statusbar overlays the
> webview, and a lot of people didn't like their UI changing especially if
> they still support iOS 6. That is the primary purpose of this plugin, but
> there are other features in there as well. In the last few weeks, there was
> a pull request (now integrated) for StatusBar.hide and StatusBar.show for
> Android as well.
>
> The issues related to the statusbar are under the label "statusbar-plugin"
> in JIRA, and there are currently 11 open issues. There are pull requests
> for it from the PhoneGap Build team that I am waiting to integrate -- not
> until we get this namespace stuff sorted out.
>
> I am not opposed to it being under the "labs" namespace. After talking to
> the Adobe team, we could also host the plugin under the PhoneGap Github
> org, but I'd rather use that as a last resort.
>
>
> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > (a) Yes.
> > (b) No -- some organizations (Adobe) don't like this, and we respect
> that.
> > We also want to point users at these plugins, so its good to have
> > developers protected by Apache.
> > (c) Sure -- so long as labs is clearly separate, and we leave them out of
> > blogs / plugin release notes, and we don't impact the rate of releases
> > (i.e. we don't force devs to test the labs plugins, just verify the
> > signatures is enough).
> > (d) I think the "guardian" of these labs plugins should be free to
> publish.
> > There is no reason they are lower quality than anything else.
> >
> >
> > Separate issue: is statusbar ready for Core? I think we should leave it
> in
> > labs for a little bit, have at least a few eyes audit the API and
> > investigate if there is any other similar work in the field before we
> make
> > users depend on this, but that it should move to core eventually.
> >
> > -Michal
> >
> >
> > On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org> wrote:
> >
> > > statusbar is already published org.apache.cordova.statusbar.
> > >
> > > And... Since these plugins are somewhat experimental and we're starting
> > the
> > > process of voting and publishing plugins to dist/, I wonder:
> > >
> > > a) Should we change the ID of these plugins to, say
> > > "org.apache.cordova.labs"
> > > b) Should we move these plugins to github and have them not under
> apache
> > > for now, e.g.: com.shazron.statusbar
> > > c) Should we just add them to the plugin release process.
> > > d) Should we just never publish them to the registry and have people
> use
> > > them via git url.
> > >
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Shazron <sh...@gmail.com>.
Some background on the statusbar plugin.
This was conceived because of iOS 7 where the statusbar overlays the
webview, and a lot of people didn't like their UI changing especially if
they still support iOS 6. That is the primary purpose of this plugin, but
there are other features in there as well. In the last few weeks, there was
a pull request (now integrated) for StatusBar.hide and StatusBar.show for
Android as well.
The issues related to the statusbar are under the label "statusbar-plugin"
in JIRA, and there are currently 11 open issues. There are pull requests
for it from the PhoneGap Build team that I am waiting to integrate -- not
until we get this namespace stuff sorted out.
I am not opposed to it being under the "labs" namespace. After talking to
the Adobe team, we could also host the plugin under the PhoneGap Github
org, but I'd rather use that as a last resort.
On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny <mm...@chromium.org> wrote:
> (a) Yes.
> (b) No -- some organizations (Adobe) don't like this, and we respect that.
> We also want to point users at these plugins, so its good to have
> developers protected by Apache.
> (c) Sure -- so long as labs is clearly separate, and we leave them out of
> blogs / plugin release notes, and we don't impact the rate of releases
> (i.e. we don't force devs to test the labs plugins, just verify the
> signatures is enough).
> (d) I think the "guardian" of these labs plugins should be free to publish.
> There is no reason they are lower quality than anything else.
>
>
> Separate issue: is statusbar ready for Core? I think we should leave it in
> labs for a little bit, have at least a few eyes audit the API and
> investigate if there is any other similar work in the field before we make
> users depend on this, but that it should move to core eventually.
>
> -Michal
>
>
> On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org> wrote:
>
> > statusbar is already published org.apache.cordova.statusbar.
> >
> > And... Since these plugins are somewhat experimental and we're starting
> the
> > process of voting and publishing plugins to dist/, I wonder:
> >
> > a) Should we change the ID of these plugins to, say
> > "org.apache.cordova.labs"
> > b) Should we move these plugins to github and have them not under apache
> > for now, e.g.: com.shazron.statusbar
> > c) Should we just add them to the plugin release process.
> > d) Should we just never publish them to the registry and have people use
> > them via git url.
> >
>
Re: [cordova-plugins/statusbar] Publishing as core
Posted by Michal Mocny <mm...@chromium.org>.
(a) Yes.
(b) No -- some organizations (Adobe) don't like this, and we respect that.
We also want to point users at these plugins, so its good to have
developers protected by Apache.
(c) Sure -- so long as labs is clearly separate, and we leave them out of
blogs / plugin release notes, and we don't impact the rate of releases
(i.e. we don't force devs to test the labs plugins, just verify the
signatures is enough).
(d) I think the "guardian" of these labs plugins should be free to publish.
There is no reason they are lower quality than anything else.
Separate issue: is statusbar ready for Core? I think we should leave it in
labs for a little bit, have at least a few eyes audit the API and
investigate if there is any other similar work in the field before we make
users depend on this, but that it should move to core eventually.
-Michal
On Wed, Mar 5, 2014 at 1:14 PM, Shazron <sh...@apache.org> wrote:
> statusbar is already published org.apache.cordova.statusbar.
>
> And... Since these plugins are somewhat experimental and we're starting the
> process of voting and publishing plugins to dist/, I wonder:
>
> a) Should we change the ID of these plugins to, say
> "org.apache.cordova.labs"
> b) Should we move these plugins to github and have them not under apache
> for now, e.g.: com.shazron.statusbar
> c) Should we just add them to the plugin release process.
> d) Should we just never publish them to the registry and have people use
> them via git url.
>