W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: Two years on and still no sensible web storage solutions exist

From: Florian Bösch <pyalot@gmail.com>
Date: Mon, 12 Nov 2012 19:27:33 +0100
Message-ID: <CAOK8ODh2WEfY6+=n-vpx5zV_6ssa03qL4AEi3hLA7LNFp4sNxw@mail.gmail.com>
To: Todd Blanchard <toddvblanchard@gmail.com>
Cc: Charles McCathie Nevile <chaals@yandex-team.ru>, Andrew Wilson <atwilson@google.com>, Webapps WG <public-webapps@w3.org>
On Mon, Nov 12, 2012 at 7:19 PM, Todd Blanchard <toddvblanchard@gmail.com>wrote:

> Gigabytes of data?  Why would one subject WebSQL to a hard quote of 5M and
> think using gigabytes of user disk space in a different scenario is OK?
>  Something seems out of balance here.  Why limit one but not the other?
The hard quota is not my idea. It's what those browsers who do implement
WebSQL implement. Unlike IndexedDB which triggers a "do you want to allow
yadda yadda" or whatever, at least sometimes, WebSQL is hard limited to 5mb.

And as to why large sizes do matter. Let's take the sponza atrium in binary
form including normals, positions, texcoords and material IDs (100mb). If
you chuck out a bunch of things you can compute, structure and otherwise
make smaller, you can get out at some 12mb. But you can't send that to the
GPU. You've got to convert it to something that's usable for the GPU, which
takes up around 1-2 seconds of CPU time in JS if you wrote a
super-optimized piece of code. Now reading 100mb from disk to a binary
representation shouldn't take more than about 80ms or so worst case. So It
would be kind of really desirable to be able to store temporary calculated
assets. Another usecase for large asset storage is productivity software
that deals with images/meshes. The amount of data you quickly generate with
that kind of software is staggering, and in the interest to keep things
easy to use it would be kinda nice to be able to manage assets on the
client other than file drop.
Received on Monday, 12 November 2012 18:28:01 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:50 UTC