cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Becky Gibson <gibson.be...@gmail.com>
Subject Re: Creating repos for core plugins
Date Wed, 06 Feb 2013 20:13:21 GMT
Well,  we still need an API/plugin for playing audio.  The w3c spec is pretty involved.  In
the past Simon has suggested we try to unify around HTML audio.  At any rate I don't think
we can just get rid of it.

Sent from my iPhone

On Feb 6, 2013, at 2:52 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> +1
> 
> 
> On Wed, Feb 6, 2013 at 2:41 PM, Brian LeRoux <b@brian.io> wrote:
> 
>> So instead of revisiting it just let it die and kick up a new one for web
>> audio?
>> 
>> On Wed, Feb 6, 2013 at 11:23 AM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>>> So... back to cordova-plugin-media then?
>>> 
>>> 
>>> On Wed, Feb 6, 2013 at 1:59 PM, Brian LeRoux <b@brian.io> wrote:
>>> 
>>>> exactly! And plugins, I think, will end up being independently
>>>> versioned so if ppl want old and busted they can have it. =P
>>>> 
>>>> On Wed, Feb 6, 2013 at 10:48 AM, Andrew Grieve <agrieve@chromium.org>
>>>> wrote:
>>>>> 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
View raw message