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 <shaz...@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 <shaz...@gmail.com> wrote: > >> https://issues.apache.org/jira/browse/INFRA-7444 >> >> >> On Thu, Mar 13, 2014 at 11:50 AM, Shazron <shaz...@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 <purplecabb...@gmail.com> wrote: >>> >>>> oops, yeah Shaz. "statusbar namespace does *not* change" >>>> >>>> @purplecabbage >>>> risingj.com >>>> >>>> >>>> On Tue, Mar 11, 2014 at 11:50 AM, Shazron <shaz...@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 <purplecabb...@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 < >>>> csantan...@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 < >>>> > agri...@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 < >>>> > > > > > jbo...@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 >>>> > > > > <csantan...@gmail.com> >>>> > > > > >>>> > > > >>>> > > >>>> > >>>> >>> >>> >> >
