OWP storage team sync - 12/6/16

[Dru Knox]

[bcc blink-dev]

• Triage
• Most of things were hotlist-recharge
• Tracking down a crash for drag and drop
• Want to mark all of our DB files not copy on write
• A few blocked on more feedback
• SQL on the web
• Want to support this use case
• Ideally, would support it by enabling polyfills (like Lovefield) on top of IDB
• Persistent storage
• Filed bug for enterprise policy to set site engagement
• Should help enterprise reliability concerns
• IDB
• Added a few tests
• Filed a few spec bugs
• CL for terminating transactions when we're under memory pressure
• CL to change transaction lifetime support
• Working on race conditions between errors
• HEIST mitigation
• CL is largely done, number of changes steadily decreasing
• Still working with security for the right padding numbers
• SQLite
• Working on write ahead logging to eliminate fsyncs at shutdown
• Ends up breaking a bunch of tests - driving those down
• Probably not appropriate for WebSQL
• Quota improvements
• CL running on CQ bots
• Need to track down an additional reviewer
• Service Workers
• Landed CL to keep SW from keeping themselves alive
• File API
• Looking at some spec issues
• Important Storage
• Engagement looks good with blacklisting changes (4% -> 10%)
• Looking to launch fully in M57
• Blob storage
• CL to configure all our ephemeral resource usage
• Filesystem API
• 95% of usage turns out to be incognito detection
• Renewed interest in removing in light of this
• Going to look into this in Q1

[alexandr...@gmail.com]

For what it can worth, few things I would like to share about Web SQL:

1. Like UDP/TCP, this a very interesting API for privileged Web Apps like:
   
   
1. installed public Web Apps which requested such permissions
2. Business Web Apps running on an Intranet (potentially accessed via a VPN)
3. installed hybrid apps built via NW.js, Electron, Cordova, NativeScript?, ReactNative?
4. Server-Side / End-to-end JavaScript usages (Wakanda, meteor, ...)
   
   
2. Official argument to have put the recommendation on hold was that "all implementations used SQLite" and "too few implementations", but...
   
   
1. As long as Web SQL could be used in privileged Web App mode, it would be really more usefull if able to connect to local network available databases
2. the fact it started to be deprecated disengaged potential implementors
   
   
3. The Web SQL API was removed from Web Worker contexts in Blink because "measured usage was very low", but...
   
   
1. Web Workers were the ideal place to use the Web SQL synchronous API (as SQL connections are occasionally implemented in Wakanda Web Workers)
2. a lot of usage is not measurable ("incognito detection" as you said for the Filesystem API) because using Opera Embedded, or "cef" (Chrome Embedded Framework) versions (such as in packaged apps, in set-top-box, ...)  

It's not just an opinion but a shared experience both my previous (Wakanda) and my current (Wiztivi) companies 

I've been a NoSQL advocate for few years in my previous work but we also still had a lot of use cases in business Web apps for SQL APIs

By the way, Wakanda Server implements the Filesystem API (as well as Web Storage, Dedicates & Shared Workers) natively on the server 

And the team was considering to implement:

• the UDP TCP Socket API* (from the System API ex-W3C WG). 
• the Web SQL for its default SQL API for network connected databases (adding some connection method) 

* Note: a first version (before integration of Streams) was implemented on a device Wiztivi developed a project on