cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <>
Subject Re: [cordova-plugins/statusbar] Publishing as core
Date Mon, 10 Mar 2014 20:07:10 GMT
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?

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.


On Mon, Mar 10, 2014 at 12:05 PM, Tommy-Carlos Williams

> +1
> On 11 Mar 2014, at 5:52 am, 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.
> >
> >
> >
> >
> > On Mon, Mar 10, 2014 at 10:30 AM, Jonathan Bond-Caron <
> >> 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  (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
> >>
> >>
> >>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message