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> >> > > > > >> > > > >> > > >> > >> > >
