Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com
 designates 209.85.212.43 as permitted sender)
MIME-Version: 1.0
Sender: brian.leroux@gmail.com
In-Reply-To: <CD37DF4F.172DC%fil@adobe.com>
References: 
 <CABiQX1WZjOEihpSWYApNCzwENXis0h6s74-CeL8y+VQKA68tPQ@mail.gmail.com>
	<CD37DF4F.172DC%fil@adobe.com>
Date: Wed, 6 Feb 2013 10:41:31 -0800
Message-ID: 
 <CADVgkyPuq4Vv+vNPk3b0=WyXebByDQSsuaBefAW2kGibPvdNcw@mail.gmail.com>
Subject: Re: Creating repos for core plugins
From: Brian LeRoux <b@brian.io>
To: dev@cordova.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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