[Bug 12620] 5MB isn't enough

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12620

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian@hixie.ch,
                   |                            |public-webapps@w3.org
          Component|HTML5 spec (editor: Ian     |Web Storage (editor: Ian
                   |Hickson)                    |Hickson)
            Product|HTML WG                     |WebAppsWG
          QAContact|public-html-bugzilla@w3.org |member-webapi-cvs@w3.org

--- Comment #3 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-05-06 19:12:29 UTC ---
(In reply to comment #2)
> Just as an FYI, i posted this here because the form on the Web Storage spec
> doesnt work. It says I don't have JS enabled, which obviously, I do. It then
> sent me here... it was a feedback on the disk space section. I can post it
> elsewhere, I just figured this was the kind of feedback you were looking
> for...? If not, what kind of info are you looking for in those forms if its not
> about the spec? Not at all trying to be sarcastic or an ass, actually curious.

Yeah, it seems to be broken.  I filed bug 12628 on it.  This is good enough,
anyway.  The component is wrong, but Ian is the editor of both specs, so it
doesn't matter much.  I'll change it to the right component for tidiness.

We're looking for feedback on the spec, yes.  However, a lot of what the spec
says is there for a good reason.  There'd be no point in changing the spec to
say a minimum of 20 MB if browsers didn't want to go along.  The 5 MB limit was
probably the result of considerable discussion.  It's enough for basic usage
without risking using up much of the user's disk.  Individual browsers can
supply more than the 5 MB requirement, much more if they want.  But they're not
likely to all have a much higher limit all the time, because it might use up
too much disk space over time, since localStorage data isn't supposed to be
deleted if possible.

There wasn't any way for you to know this, though.  Thanks for the feedback
anyway.  The editor will get around to officially responding to it at some
point.

> Everyone says that it has to be synchronous but I honestly can't find that
> anywhere in the spec. It could be async easily and I actually don't understand
> why it couldnt?

In JavaScript terms, synchronous APIs are ones where you do something and then
the next line of code doesn't run until the first line is complete.  For
instance, if you do

  localStorage["foo"] = 1;
  alert(localStorage["foo"]);

then it will alert "1" (if nothing else is modifying localStorage at the same
time, like the same site in another tab).  For this to be reliably true, the
first line must completely finish, with the data submitted to at least
temporary storage, before the second line is run.  That's what we mean by
"synchronous".

An asynchronous API in JavaScript is where you register an event handler.  For
instance, code similar to the above in IndexedDB would be something like . . .
well, I won't try to replicate it, too complicated.  But this should give the
basic idea.  If store has been initialized to an object store:

  store.add({foo: 1}).onsuccess = function(event) {
    alert("foo has been set to 1");
  }
  alert("Some other code");

What this does is call store.add() to do the actual adding of the new value. 
That does nothing except return an IDBRequest object immediately.  The code
sets the onsuccess property of the object to a function that will be fired when
the add() operation is successful.  Then it does nothing else at present, so it
alerts "Some other code".  When the add() is successful, the browser queues a
success event to fire at the object the next time it needs to run a task.  Then
that alerts "foo has been set to 1".

The key thing here is that if it takes a while to do reads or writes or such,
script doesn't stop running.  The event just won't fire for a while. 
JavaScript in browsers is single-threaded, so if the browser gets stuck
executing a particular line, all script has to freeze.  This typically means
the whole page freezes.  With purely asynchronous APIs, nothing will freeze
even if some event takes a while.

> Also, yes, obviously allowing 1GB or unlimited data on all sites wouldn't work,
> but im just saying give the choice to the user. If, for example, photoshop.com
> needed 10GBs of data I would give it to them as I need it for the site and I
> know what its being used for. Now, if i go to some random site after googling
> something and it asks to store that much I would say no. I dont see what the
> issue is if its the user making the choice.

This is a possibly valid argument, but what the specification says isn't likely
to change what browsers do here.  For open-source browsers like Firefox or
Chromium, you can try asking on a relevant discussion list.  Generally,
browsers prefer not to ask the user to make too many choices, especially when
most users have only a vague idea of what disk space is and can't give an
informed answer.  Browsers will change when they have authors asking them to
change.

> IndexedDB, again, is nice and powerful, but so, so, so much
> more complicated than localStorage. I'll learn it as it looks super cool, but
> for most stuff it seems like its a little heavy.

Yeah, it seems awfully hard to deal with . . .

> Lastly, I know, I talked to the Chrome team awhile ago and, if you read my
> blog, they basically just called the entire idea of raising it even 5MBs stupid
> even tho all the other people aside from the Chrome team wanted it. They also
> said localStorage in general was just a stupid idea, so when I saw the
> suggestion box I thought it was the right place to do it. Sorry!

There are a lot of implementers who are unhappy with localStorage and don't
want to encourage its use too much, yeah.  The fact that it's synchronous (=
can easily freeze your entire web page perceptibly every time it's invoked) has
a lot to do with that.  Kind of a shame, since IndexedDB is horrendously
complicated, but there you have it.  (Seems IDB has fallen into the "let's make
a highly general and complicated API and hope authors paper over it with
something usable" trap.)

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 6 May 2011 19:12:32 UTC