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 <[email protected]> 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 <[email protected]> wrote: > > Totally makes sense to separate them. > > > > File is spec-based, FileTransfer is not. > > > > On 2/6/13 10:16 AM, "Andrew Grieve" <[email protected]> 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 > >><[email protected]>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 <[email protected]> > >>> 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 <[email protected]> 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 > >>><[email protected]> > >>> > > 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 > >>><[email protected]> > >>> > > 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 > >>><[email protected] > >>> > > >>> > > >> 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 <[email protected]> > >>> wrote: > >>> > > >> > > >>> > > >> >> +1 on separate repos. It's the sane choice. > >>> > > >> >> > >>> > > >> >> > >>> > > >> >> On Mon, Feb 4, 2013 at 11:53 PM, Jesse > >>><[email protected]> > >>> > > 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 < > >>> [email protected] > >>> > > > >>> > > >> >> 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 <[email protected] > > > >>> > 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 < > >>> > > >> [email protected] > >>> > > >> >> > > >>> > > >> >> > > > 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 > >>> > > >> >> > > >>> > > >> >> > >>> > > >> > > >>> > > >> > > >>> > > >> > >>> > > > >>> > > >>> > > >
