cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [cordova-plugins/statusbar] Publishing as core
Date Thu, 13 Mar 2014 19:43:49 GMT
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 <shazron@gmail.com> wrote:

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

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