cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [Android] Plugins to send on the ice flows to die
Date Sat, 23 Mar 2013 00:42:32 GMT
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 <fil@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" <bowserj@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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message