+1 to not reinventing the wheel and sanctioning external contributions if
they are available, Joe.

Having said that, personally I'd prefer to see an IndexedDB-like-thing
instead of a WebSQL-like-thing since thats the direction all desktop
browsers have gone, and maps better to web developer
expectations/abilities.  Also, there is hope that one day mobile webviews
will support IndexedDB and we can remove our polyfills, and the reverse is
not true, so I think an IDB polyfill aligns better with cordova goals.

-Michal


On Thu, Sep 19, 2013 at 7:38 AM, Joe Bowser <bows...@gmail.com> wrote:

> OK, here's a crazy concept that I'm going to throw out there.
>
> How about we audit and recommend a third-party plugin and not do any
> more work on this issue.  I know that Android has a SQLite plugin that
> works like WebSQL, but has a slightly different namespace. I haven't
> recommended it because I don't feel comfortable doing that not knowing
> how good it works.  Then once we give our rubber stamp on that plugin,
> we let our current solutions go on the ice flows to die.
>
> What do people think of that idea?  I'd rather not re-invent the wheel
> if I don't have to.
>
> On Thu, Sep 19, 2013 at 7:30 AM, Braden Shepherdson <bra...@chromium.org>
> wrote:
> > The troubling part here is that WebSQL is broken (iOS7 introduced new
> bugs,
> > too!) on iOS and Android, not supported on non-Webkit browsers, and crap.
> > But... IndexedDB is arguably more crap, though less buggy, but it isn't
> > supported on /anything/ mobile to my knowledge. This has been a crippling
> > problem when our chrome-apps-on-cordova team has been porting apps. If
> some
> > app uses IndexedDB, we're out of luck.
> >
> > There is a shim that uses WebSQL as a back-end for IndexedDB, intended
> to be
> > used on these devices. But then it's still crap and buggy. I started
> poking
> > at it to see if I could replace this with a shim of IndexedDB with a
> Cordova
> > plugin (maybe File, more likely something specialized) as the backend.
> > That's probably possible, though it was complicated in a couple of
> places by
> > the fact that some IDB/WebSQL calls are sync but all Cordova native calls
> > are async. Probably still possible to do that port, if we think it's
> > worthwhile. It would be a nontrivial project, though, and the IDB
> interface
> > and performance still suck.
> >
> > Braden
> >
> >
> >
> >
> > On Thu, Sep 19, 2013 at 8:08 AM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >> Deprecated.
> >> On Sep 19, 2013 5:04 AM, "Andrew Grieve" <agri...@chromium.org> wrote:
> >>
> >> > If it's easy to support, then I think it's worth doing.
> >> >
> >> > A custom scheme would work, but I think we can do it with a less
> >> > intrusive
> >> > change:
> >> >
> >> > We came up with the following hack during our chrome-apps-on-cordova
> >> > work
> >> > for having CORS work when on a custom scheme. Should work for WebSQL
> as
> >> > well though. It takes advantage of the fact that file:/// pages can
> >> > access
> >> > window objects of opened windows that are on different domains. It
> goes
> >> > like:
> >> >
> >> > The JS Code:
> >> >
> >> > var win = window.open("websql://ftw");
> >> > // wait for window to load. Maybe via onload event? Or via polling?
> >> > win.onload = function() {
> >> >   window.openDatabase = win.openDatabase;
> >> > }
> >> >
> >> >
> >> > // The Java code:
> >> > app.getSettings().setSupportMultipleWindows(true);
> >> >
> >> > // In Chrome Client:
> >> >     @SuppressWarnings("unused")
> >> >     private WebView newWebView = null;
> >> >     public boolean onCreateWindow (WebView view, boolean isDialog,
> >> > boolean
> >> > isUserGesture, Message resultMsg) {
> >> >         WebView.WebViewTransport transport =
> (WebView.WebViewTransport)
> >> > resultMsg.obj;
> >> >         newWebView = new WebView(act);
> >> >         newWebView.getSettings().setJavaScriptEnabled(true);
> >> >
> >> >         newWebView.setWebViewClient(new WebViewClient(){
> >> >                 @Override
> >> >                 public WebResourceResponse
> shouldInterceptRequest(final
> >> > WebView view, String url) {
> >> >                         return a response that is just an empty page.
> >> >                 }
> >> >         });
> >> > transport.setWebView(newWebView);
> >> >         resultMsg.sendToTarget();
> >> >         return true;
> >> >     }
> >> >
> >> >
> >> > On Wed, Sep 18, 2013 at 7:43 PM, Jesse <purplecabb...@gmail.com>
> wrote:
> >> >
> >> > > Windows Phone has never supported it.  I have always felt that this
> is
> >> > more
> >> > > of a browser responsibility and didn't belong in the 'phonegap
> >> > > features'
> >> > > matrix. Just like we don't list querySelectorAll or SVG support.
> >> > >
> >> > > Someone needs to write a JS shim that uses the File API which IS
> >> > available
> >> > > on all the devices in cordova.
> >> > >
> >> > > @purplecabbage
> >> > > risingj.com
> >> > >
> >> > >
> >> > > On Wed, Sep 18, 2013 at 2:31 PM, Joe Bowser <bows...@gmail.com>
> wrote:
> >> > >
> >> > > > Ok, We've been ignoring this for quite a while, but it's not going
> >> > away:
> >> > > >
> >> > > > There's still people who want to use WebSQL, and WebSQL is still
> >> > > > totally broken.  Part of the reason it's broken is the fact that
> >> > > > Android prevents us from using the official WebSQL API on file
> URIs,
> >> > > > and that we have a nasty collision with the official API on
> Android.
> >> > > >
> >> > > > So, what should we do?
> >> > > > 1. Use a custom URI scheme?
> >> > > > 2. Fix the JS so it aliases the existing WebSQL, and keep using
> our
> >> > > > own WebSQL plugin.
> >> > > > 3. Just say it's deprecated and leave it at that?
> >> > > >
> >> > > > If we say we're tossing WebSQL by the wayside, what do we support
> >> > > > instead?  Seriously, what do people think of this, because I'm not
> >> > > > sure what we should do here.
> >> > > >
> >> > > > Joe
> >> > > >
> >> > >
> >> >
> >
> >
>

Reply via email to