RE: Geolocation… wouldn't moving to the browser implementation lead to a sub 
par experience when (as I have mentioned) the end user is asked for permission 
(in iOS as an example)?

I really wouldn't want users of my apps to have a dialog pop up telling them 
that "index.html" wants something :)

Isn't the Cordova implementation what is making that nicer and allowing for the 
"app" to ask for permission?


On 26/03/2013, at 3:12 AM, Lorin Beer <lorin.beer....@gmail.com> 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?! <http://www.w3.org/TR/webdatabase/>
> 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 
> <bra...@chromium.org>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 <shaz...@gmail.com> wrote:
>> 
>>> It was - but then the draft spec changed, inevitably :)
>>> 
>>> 
>>> On Sun, Mar 24, 2013 at 9:35 AM, Ken Wallis <kwal...@blackberry.com>
>>> 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 <kwal...@blackberry.com>
>>>> 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 <agri...@chromium.org
>>> 
>>>>> wrote:
>>>>> 
>>>>>> What's the alternative to Camera?
>>>>>> 
>>>>>> 
>>>>>> On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj <f...@adobe.com> 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" <bows...@gmail.com> 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.
>>>> 
>>> 
>> 

Reply via email to