Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 477F6F9EB for ; Mon, 25 Mar 2013 16:24:31 +0000 (UTC) Received: (qmail 46720 invoked by uid 500); 25 Mar 2013 16:24:31 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 46694 invoked by uid 500); 25 Mar 2013 16:24:31 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 46685 invoked by uid 99); 25 Mar 2013 16:24:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Mar 2013 16:24:30 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lorin.beer.dev@gmail.com designates 209.85.210.169 as permitted sender) Received: from [209.85.210.169] (HELO mail-ia0-f169.google.com) (209.85.210.169) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Mar 2013 16:24:25 +0000 Received: by mail-ia0-f169.google.com with SMTP id j5so5757040iaf.0 for ; Mon, 25 Mar 2013 09:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=hB1k7LKfjim+Jp40fReBrk6AG2UUZPrqOt+EZDLXVvI=; b=aDDzmni6tPzLjkWsKS5dp+mQZgixTcWojE6BSXkUibe7e9sQ1v9kCc9n8Tst1dPNAC gu+YimE1gubSOQ4wvOp/8lMasIRGISGX6K+/zrL1rP+lnvARjRqAG0Ji5Wo6d2MR4cPg b7ZZGElPP+KWWQN/qrs1y1HdgECa0CEC2bymUJjcCjE0dWhkxqO1gLQWRYW5JvIwLdtZ /zcFgYy5YiHYpkHpBmL5ZsNetqxHT52+zxY+n3ca7m0sVshmE58Rk5IAnvTC2ttwYAeS R8aCDWtdCD2QYeG2uZQZD5rNVqVu9VNk6tHtyBw2KzSg296tLRXOsFesROvDrl8zD11S /9Iw== MIME-Version: 1.0 X-Received: by 10.50.17.131 with SMTP id o3mr8509393igd.112.1364228643899; Mon, 25 Mar 2013 09:24:03 -0700 (PDT) Received: by 10.64.8.167 with HTTP; Mon, 25 Mar 2013 09:24:03 -0700 (PDT) In-Reply-To: References: <20130323021631.6111385.69450.1853@blackberry.com> <20130324163532.14672015.21301.1950@blackberry.com> Date: Mon, 25 Mar 2013 09:24:03 -0700 Message-ID: Subject: Re: [Android] Plugins to send on the ice flows to die From: Lorin Beer To: dev@cordova.apache.org Content-Type: multipart/alternative; boundary=14dae934049fb69f6104d8c23b47 X-Virus-Checked: Checked by ClamAV on apache.org --14dae934049fb69f6104d8c23b47 Content-Type: text/plain; charset=ISO-8859-1 it's a valid point, and I'm not too sure how to handle that. Deprecating our polyfill would be the obvious suggestion, but the whole point is to let these plugins die, not continue to include potentially broken/breakable code in future releases. How far back does WebSQL support go on Droid? On Mon, Mar 25, 2013 at 9:16 AM, Simon MacDonald wrote: > The thing that worries me about killing our websql support is that we > will get a situation where websql will be available on some versions > of Android but not on others because we have removed our polyfil. > > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Mon, Mar 25, 2013 at 12:12 PM, Lorin Beer > wrote: > > +1 for Geolocation > > Joe's reasoning is convincing: when native functionality exceeds/matches > > what were providing, what's the point? > > > > and a huge +1 for WebSQL, I believe W3C deprecated the spec in November > > 2011? 2010?! > > Being proactive about this and deprecating/removing our own support for > > this api now strikes me as a far better move than waiting for WebKits to > > break it. Not to mention the brittleness and exception issues Joe > mentioned. > > > > > > On Mon, Mar 25, 2013 at 7:22 AM, Braden Shepherdson >wrote: > > > >> +1 to killing WebSQL after we have IndexedDB support. It's no longer the > >> standard and only exists in Webkit. The IndexedDB support doesn't exist > at > >> all in Android browser or iOS Safari though (a surprise to me, at > least), > >> according to caniuse.com[1] > >> > >> It isn't our job to maintain APIs that have been deprecated for a year, > >> though we can keep WebSQL around if we want. > >> > >> Braden > >> > >> > >> On Sun, Mar 24, 2013 at 2:05 PM, Shazron wrote: > >> > >> > It was - but then the draft spec changed, inevitably :) > >> > > >> > > >> > On Sun, Mar 24, 2013 at 9:35 AM, Ken Wallis > >> > wrote: > >> > > >> > > Thanks Shaz. I had thought that the Cordova Capture API was already > >> based > >> > > on the Media Capture spec, should have looked closer. ;) > >> > > > >> > > Sent from my BlackBerry Z10 smartphone. > >> > > From: Shazron > >> > > Sent: Saturday, March 23, 2013 9:20 PM > >> > > To: dev@cordova.apache.org > >> > > Reply To: dev@cordova.apache.org > >> > > Subject: Re: [Android] Plugins to send on the ice flows to die > >> > > > >> > > > >> > > Ken, > >> > > From here: http://wiki.apache.org/cordova/Core%20API%20Audit > >> > > It will bring you eventually to here (Media Capture - getusermedia): > >> > > http://dev.w3.org/2011/webrtc/editor/getusermedia.html > >> > > and there's also HTML Media Capture: > >> > > http://www.w3.org/TR/html-media-capture/ > >> > > > >> > > > >> > > On Fri, Mar 22, 2013 at 7:16 PM, Ken Wallis > > >> > > wrote: > >> > > > >> > > > What spec is that? I would like to research that, I was not aware > >> there > >> > > > was a new one. > >> > > > > >> > > > Thanks! > >> > > > > >> > > > Sent from my BlackBerry Z10 smartphone. > >> > > > From: Shazron > >> > > > Sent: Friday, March 22, 2013 8:43 PM > >> > > > To: dev@cordova.apache.org > >> > > > Reply To: dev@cordova.apache.org > >> > > > Subject: Re: [Android] Plugins to send on the ice flows to die > >> > > > > >> > > > > >> > > > Andrew: Capture API. But that's going away I reckon as well (there > >> is a > >> > > new > >> > > > spec) > >> > > > > >> > > > > >> > > > On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve < > agrieve@chromium.org > >> > > >> > > > wrote: > >> > > > > >> > > > > What's the alternative to Camera? > >> > > > > > >> > > > > > >> > > > > On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj > wrote: > >> > > > > > >> > > > > > +1 geo and websql deprecation > >> > > > > > > >> > > > > > I would wait on camera until we actually do the api audit > >> > > > > > > >> > > > > > On 3/22/13 2:54 PM, "Joe Bowser" wrote: > >> > > > > > > >> > > > > > >Hey > >> > > > > > > > >> > > > > > >I'm currently looking through the plugins, and I'm thinking > more > >> > and > >> > > > > > >more that Android has at least two plugins that I would like > to > >> > see > >> > > no > >> > > > > > >longer maintained once we break them off of the main > repository. > >> > > > > > > > >> > > > > > >Geolocation: > >> > > > > > >------------------- > >> > > > > > >Our Geolocation doesn't actually give us anything that the > >> browser > >> > > > > > >doesn't do. I think that GPS could be done better, and that > the > >> > spec > >> > > > > > >sucks. However our core plugins are supposed to follow the > spec, > >> > and > >> > > > > > >since the browser on Android does this much better, there's > no > >> > point > >> > > > > > >for this plugin to exist. > >> > > > > > > > >> > > > > > >WebSQL Storage: > >> > > > > > >---------------------------- > >> > > > > > >Our WebSQL storage is pretty brittle and is just a shim to > the > >> raw > >> > > > > > >SQLite that Android creates. There's no real exception > handling, > >> > and > >> > > > > > >this could easily crash. I would like to deprecate this and > >> point > >> > > > > > >people to a third party plugin if they need their SQLite > done. > >> > > > > > > > >> > > > > > >Camera > >> > > > > > >-------------- > >> > > > > > >Also, we need to figure out how we capture things. It'd be > good > >> if > >> > > we > >> > > > > > >picked one way to do this over the other. Right now > mobile-spec > >> > > seems > >> > > > > > >to use the Camera API, which I don't think is correct. We > need > >> to > >> > > > > > >write a new test for this, because right now this isn't well > >> > tested. > >> > > > > > >I'd like to send the old Camera API on the ice flow in > favour of > >> > > > > > >capture and the native URI handling. > >> > > > > > > > >> > > > > > >Thoughts on this? > >> > > > > > > > >> > > > > > >Joe > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > --------------------------------------------------------------------- > >> > > > This transmission (including any attachments) may contain > >> confidential > >> > > > information, privileged material (including material protected by > the > >> > > > solicitor-client or other applicable privileges), or constitute > >> > > non-public > >> > > > information. Any use of this information by anyone other than the > >> > > intended > >> > > > recipient is prohibited. If you have received this transmission in > >> > error, > >> > > > please immediately reply to the sender and delete this information > >> from > >> > > > your system. Use, dissemination, distribution, or reproduction of > >> this > >> > > > transmission by unintended recipients is not authorized and may be > >> > > unlawful. > >> > > > > >> > > > >> > > > >> > > > --------------------------------------------------------------------- > >> > > This transmission (including any attachments) may contain > confidential > >> > > information, privileged material (including material protected by > the > >> > > solicitor-client or other applicable privileges), or constitute > >> > non-public > >> > > information. Any use of this information by anyone other than the > >> > intended > >> > > recipient is prohibited. If you have received this transmission in > >> error, > >> > > please immediately reply to the sender and delete this information > from > >> > > your system. Use, dissemination, distribution, or reproduction of > this > >> > > transmission by unintended recipients is not authorized and may be > >> > unlawful. > >> > > > >> > > >> > --14dae934049fb69f6104d8c23b47--