cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: [cordova-plugins/statusbar] Publishing as core
Date Mon, 10 Mar 2014 16:51:02 GMT
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 <agrieve@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 <shazron@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 <anis.kadri@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 <wjamesjong@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 <purplecabbage@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 <shazron@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 <shazron@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.
> > > >>
> > >
> >
>

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