W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

[whatwg] Structured clone algorithm on LocalStorage

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 23 Sep 2009 15:11:13 -0700
Message-ID: <63df84f0909231511l587f8093wc7563ca2bb4de12e@mail.gmail.com>
On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> What are the use cases for wanting to store data beyond strings (and what
> can be serialized into strings) in LocalStorage? ?I can't think of any that
> outweigh the negatives:
> 1) ?From previous threads, I think it's fair to say that we can all agreed
> that LocalStorage is a regrettable API (mainly due to its synchronous
> nature). ?If so, it seems that making it more powerful and thus more
> attractive to developers is just asking for trouble. ?After all, the more
> people use it, the more lock contention there'll be, and the more browser UI
> jank users will be sure to experience. ?This will also be worse because
> it'll be easier for developers to store large objects in LoaclStorage.
> 2) ?As far as I can tell, there's no where else in the spec where you have
> to serialize structured clone(able) data to disk. ?Given that LocalStorage
> is supposed to throw an exception if any ImageData is contained and since
> File and FileData objects are legal, it seems as though making LocalStorage
> handle structured clone data has a fairly high cost to implementors. ?Not to
> mention that disallowing ImageData in only this one case is not intuitive.
> I think allowing structured clone(able) data in LocalStorage is a big
> mistake. ?Enough so that, if SessionStorage and LocalStorage can't diverge
> on this issue, it'd be worth taking the power away from SessionStorage.

Despite localStorage unfortunate locking contention problem, it's
become quite a popular API. It's also very successful in terms of
browser deployment since it's available in at least latest versions of
IE, Safari, Firefox, and Chrome. Don't know about support in Opera?

Browser UI jank isn't a problem as far as I can tell though. In
multi-process browsers the browser UI generally runs in a process
separate from the web page and so is not affected by the lock. In
single process browsers no lock is needed as there aren't multiple
processes that can access the localStorage at the same time.

Any time you store data into localStorage it seems useful to store
structured data. Say for example an webmail implementation storing
emails in each localStorage entry, in this case it would be possible
to store email body, from, to, date, flags, etc in a structured way.

Another reason is the ability to store file objects. This is something
that's important in order to be able to implement for example offline
email with attachments.

Note that while storing File objects is supported, you don't actually
need to store the data in it synchronously. Instead you can
asynchronously stream the filedata anyplace, and simply store a
pointer in the localStorage to that location.

/ Jonas
Received on Wednesday, 23 September 2009 15:11:13 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC