cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Creating repos for core plugins
Date Wed, 06 Feb 2013 18:48:24 GMT
SGTM. First step towards deprecation is turning it into a plugin so that
people can not install it :)


On Wed, Feb 6, 2013 at 1:41 PM, Brian LeRoux <b@brian.io> wrote:

> I was thinkin we'd just deprecate the media spec altogether for a
> starter/subset of the web audio api (perhaps polyfil the audio element
> while we're at it).
>
> .... should we kick up a thread about that?
>
> (Added file transfer to the non-spec plugins.)
>
>
> On Wed, Feb 6, 2013 at 10:22 AM, Filip Maj <fil@adobe.com> wrote:
> > Totally makes sense to separate them.
> >
> > File is spec-based, FileTransfer is not.
> >
> > On 2/6/13 10:16 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >
> >>I thought FileTransfer was a part of File. Maybe it makes sense to
> >>separate
> >>them though?
> >>
> >>
> >>On Wed, Feb 6, 2013 at 12:00 PM, Becky Gibson
> >><gibson.becky@gmail.com>wrote:
> >>
> >>> Yes, I shouldn't have confused the issue about audio and media!  I
> >>>guess I
> >>> just get annoyed when I go to mobile spec and it is labelled as "audio"
> >>>:-)
> >>>  We can leave it as cordova-plugin-media so it matches the JS api name.
> >>>  Although, I think we are creating the same type of confusion if we
> >>>rename
> >>> capture to media-capture but I don't have a strong opinion on that.
> >>>Plus,
> >>> I see we are doing that for acceleration and compass as well.  I guess
> >>>now
> >>> is as good a time as any to match the W3C names!
> >>>
> >>>  Also, where is FileTransfer?
> >>>
> >>>
> >>> On Wed, Feb 6, 2013 at 11:12 AM, Andrew Grieve <agrieve@chromium.org>
> >>> wrote:
> >>>
> >>> > Great! I like the spec-based names. I think I have the opposite
> >>>thought
> >>> as
> >>> > Becky. Our current media plugin doesn't follow the WebAudio spec at
> >>>all.
> >>> > How about we call it cordova-media for now since that's what it's
> >>>called
> >>> in
> >>> > our docs, and then if we ever implement WebAudio, then we'll have the
> >>> name
> >>> > available for that. Maybe we should even put it the spec-less
> category
> >>> > (unless there's some older spec that it was based off of?)
> >>> >
> >>> >
> >>> > On Tue, Feb 5, 2013 at 5:14 PM, Brian LeRoux <b@brian.io> wrote:
> >>> >
> >>> > > Just kicked up a quick wiki page to help vett this. I'm thinking
we
> >>> > > try to stay as close to the spec names as possible.
> >>> > >
> >>> > > http://wiki.apache.org/cordova/Core%20Plugin%20Name%20Proposal
> >>> > >
> >>> > >
> >>> > > On Tue, Feb 5, 2013 at 11:40 AM, Becky Gibson
> >>><gibson.becky@gmail.com>
> >>> > > wrote:
> >>> > > > My only comment would be about media.  Currently it just
supports
> >>> audio
> >>> > > so
> >>> > > > perhaps codova-plugin-audio makes more sense and we can leave
> >>>media
> >>> > open
> >>> > > > for the rewrite.  Although, I do realize the api is labelled
> >>>"media"
> >>> so
> >>> > > > perhaps it would be too confusing to change the repo name.
 Just
> a
> >>> > > > thought.....
> >>> > > >
> >>> > > >
> >>> > > > On Tue, Feb 5, 2013 at 1:38 PM, Andrew Grieve
> >>><agrieve@chromium.org>
> >>> > > wrote:
> >>> > > >
> >>> > > >> Before I go ahead with this, let's agree upon the repo
names /
> >>>which
> >>> > > >> plugins to include.
> >>> > > >>
> >>> > > >> Here's the proposed list:
> >>> > > >>
> >>> > > >> Repos to create:
> >>> > > >>
> >>> > > >> cordova-plugin-accelerometer
> >>> > > >> cordova-plugin-battery
> >>> > > >> cordova-plugin-camera
> >>> > > >> cordova-plugin-capture
> >>> > > >> cordova-plugin-compass
> >>> > > >> cordova-plugin-contacts
> >>> > > >> cordova-plugin-device
> >>> > > >> cordova-plugin-file
> >>> > > >> cordova-plugin-geolocation
> >>> > > >> cordova-plugin-globalization
> >>> > > >> cordova-plugin-logger
> >>> > > >> cordova-plugin-media
> >>> > > >> cordova-plugin-networkstatus
> >>> > > >> cordova-plugin-notification
> >>> > > >> cordova-plugin-splashscreen
> >>> > > >> cordova-plugin-inappbrowser
> >>> > > >>
> >>> > > >> Note that I have device and network status in this list.
Plugins
> >>> that
> >>> > > delay
> >>> > > >> ondeviceready just add themselves to
> >>> channel.deviceReadyChannelsArray.
> >>> > > >>
> >>> > > >> Plugins *not* getting their own Repo:
> >>> > > >>
> >>> > > >> blackberry/plugin/java/app
> >>> > > >> android/plugin/android/app
> >>> > > >> android/plugin/android/storage
> >>> > > >> errgen/plugin/errgen
> >>> > > >> ios/plugin/ios/console (seems like this should be merged
into
> the
> >>> > logger
> >>> > > >> plugin)
> >>> > > >> windowsphone/plugin/windowsphone/DOMStorage
> >>> > > >> windowsphone/plugin/windowsphone/XHRPatch
> >>> > > >> windowsphone/plugin/windowsphone/console
> >>> > > >> iOS's CDVLocalStorage.m
> >>> > > >>
> >>> > > >>
> >>> > > >> On Tue, Feb 5, 2013 at 9:34 AM, Andrew Grieve
> >>><agrieve@chromium.org
> >>> >
> >>> > > >> wrote:
> >>> > > >>
> >>> > > >> > Great! Sounds like an agreement :). I'll file an
INFRA to get
> >>>them
> >>> > > >> created.
> >>> > > >> >
> >>> > > >> >
> >>> > > >> > On Mon, Feb 4, 2013 at 9:44 PM, Shazron <shazron@gmail.com>
> >>> wrote:
> >>> > > >> >
> >>> > > >> >> +1 on separate repos. It's the sane choice.
> >>> > > >> >>
> >>> > > >> >>
> >>> > > >> >> On Mon, Feb 4, 2013 at 11:53 PM, Jesse
> >>><purplecabbage@gmail.com>
> >>> > > wrote:
> >>> > > >> >>
> >>> > > >> >> > +1, I agree on the separate repositories.
> >>> > > >> >> > I still contend that nothing should need
to be 'built' and
> >>> there
> >>> > > >> should
> >>> > > >> >> be
> >>> > > >> >> > NO dependencies on the plugins from cordova-js,
( aside
> from
> >>> > > >> device.js +
> >>> > > >> >> > network.js which are both required pre
device ready, and I
> >>> think
> >>> > > >> should
> >>> > > >> >> > remain in the cordova-js repo )
> >>> > > >> >> >
> >>> > > >> >> >
> >>> > > >> >> >
> >>> > > >> >> > On Mon, Feb 4, 2013 at 2:46 PM, Anis KADRI
<
> >>> anis.kadri@gmail.com
> >>> > >
> >>> > > >> >> wrote:
> >>> > > >> >> >
> >>> > > >> >> > > +1 for separate repositories. Should
take a bit longer
> >>>than
> >>> > > normal
> >>> > > >> to
> >>> > > >> >> > > package a release but not too long
especially if the
> repos
> >>> are
> >>> > > >> pulled
> >>> > > >> >> > from
> >>> > > >> >> > > a local source (ie no network overhead).
> >>> > > >> >> > > I'd be ok to ship a set of default
plugins and give the
> >>> ability
> >>> > > for
> >>> > > >> >> > people
> >>> > > >> >> > > to build their 'own' Cordova.
> >>> > > >> >> > >
> >>> > > >> >> > >
> >>> > > >> >> > > On Mon, Feb 4, 2013 at 2:11 PM, Brian
LeRoux <b@brian.io
> >
> >>> > wrote:
> >>> > > >> >> > >
> >>> > > >> >> > > > I'm in favor of discreet plugin
repos. It shouldn't
> >>>effect
> >>> a
> >>> > > >> release
> >>> > > >> >> > > > if we automate install/remove
and add to the Coho
> >>>tool...
> >>> > > though
> >>> > > >> >> > > > perhaps this is a naive assumption.
> >>> > > >> >> > > >
> >>> > > >> >> > > > On Mon, Feb 4, 2013 at 1:44 PM,
Andrew Grieve <
> >>> > > >> agrieve@chromium.org
> >>> > > >> >> >
> >>> > > >> >> > > > wrote:
> >>> > > >> >> > > > > Thought it'd be worth having
a discussion around
> >>>whether
> >>> we
> >>> > > >> want a
> >>> > > >> >> > > > separate
> >>> > > >> >> > > > > repo for each core plugin
or not.
> >>> > > >> >> > > > >
> >>> > > >> >> > > > > As far as I can see, we
can either have all core
> >>>plugins
> >>> in
> >>> > > one
> >>> > > >> >> repo,
> >>> > > >> >> > > or
> >>> > > >> >> > > > > have each in it's own and
call them:
> >>> > > >> >> > > > > cordova-plugin-file
> >>> > > >> >> > > > > cordova-plugin-network
> >>> > > >> >> > > > > cordova-plugin-media
> >>> > > >> >> > > > > etc...
> >>> > > >> >> > > > >
> >>> > > >> >> > > > > I think my preference would
be to have them as their
> >>>own
> >>> > > repos
> >>> > > >> so
> >>> > > >> >> > that
> >>> > > >> >> > > it
> >>> > > >> >> > > > > will be easier to add/remove
lists of plugins to the
> >>> "which
> >>> > > ones
> >>> > > >> >> are
> >>> > > >> >> > > > core"
> >>> > > >> >> > > > > list. It will also let us
version them separately (if
> >>>we
> >>> > > want to
> >>> > > >> >> do
> >>> > > >> >> > > > this).
> >>> > > >> >> > > > >
> >>> > > >> >> > > > > The downside is that it
may take longer to perform a
> >>> > release?
> >>> > > >> >> Would
> >>> > > >> >> > we
> >>> > > >> >> > > > even
> >>> > > >> >> > > > > bundle the plugins with
releases anyways though?
> >>> > > >> >> > > >
> >>> > > >> >> > >
> >>> > > >> >> >
> >>> > > >> >> >
> >>> > > >> >> >
> >>> > > >> >> > --
> >>> > > >> >> > @purplecabbage
> >>> > > >> >> > risingj.com
> >>> > > >> >> >
> >>> > > >> >>
> >>> > > >> >
> >>> > > >> >
> >>> > > >>
> >>> > >
> >>> >
> >>>
> >
>

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