Ah. Then I'll shut up ;)

On 26/03/2013, at 11:56 AM, Filip Maj <f...@adobe.com> wrote:

> In this particular case Joe was just speaking about Android.
> 
> On 3/25/13 5:45 PM, "Tommy-Carlos Williams" <to...@devgeeks.org> wrote:
> 
>> 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