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