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

[whatwg] Structured clone algorithm on LocalStorage

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 2 Oct 2009 15:07:17 -0700
Message-ID: <5dd9e5c50910021507r72ba1a06r81463addd643e8cb@mail.gmail.com>
Sorry for breaking the continuity of this thread, but since the original
topic was never really resolved, I wanted to jump back a bit.

Since my original post, I've continued thinking about LocalStorage,
structured clones, etc...and the more I've thought about it, the more
convinced I am that adding such support is a big mistake.  One way to think
about it is as follows:

1)  We've all pretty much agreed that localStorage's synchronous design was
a mistake that we should be careful to not repeat.
2)  I think we can all agree that storing structured clone data makes
LocalStorage more powerful and useful to developers.
3)  And I think we can all agree that developers like to use more powerful
APIs.  Especially when the API is easy to use and understand (as
LocalStorage is).
4)  Lock contention becomes worse as the frequency of acquires and/or the
duration the lock is held increases.

Although there might be some subtleties about the statements I made that
people could argue with, I think all these statements are pretty
fundamentally true.  Assuming so, it's not a stretch to see that 2 and 3
imply that adding structured clones to local storage will lead to more use
of local storage.  If use increases, then 4 implies that the storage lock is
going to become a bigger problem over time.  Since we can all agree that the
synchronous design of local storage is already a problem that we wish we had
avoided, I just can't understand why we're happy to make it a bigger

Does anyone have an argument against this?

Personally I find this argument especially compelling for the following
reason:  Anyone who's going to use LocalStorage in the near to medium future
will need to handle the case of LocalStorage only handling strings.  This is
because structured clones supports a super-set of what can be serialized
within a script, there's no way for libraries to build a transparent
compatibility abstraction.  Thus, for some time, developers will either need
to only use data that can be serialized (thus making structured clones only
a performance optimization) or developers will need to cut off browsers that
don't support structured clones.

Assuming that, we're basically saying that structured clones is a feature
for the long term use and health of LocalStorage.  Now I know that we can't
just get rid of LocalStorage and coming up with viable alternatives will
take some time, but do we really believe that we can't agree on and develop
a better alternative in the mean time?

I'm fine with SessionStorage supporting structured clones.  I just don't
think we should make LocalStorage any more powerful.  In fact, at this
point, I think we should redirect all the time and effort we're putting into
making LocalStorage better (including solving lock contention issues) and
instead put it into creating a new API that solves these problems and that
all the browser vendors can get behind.  (If you have ideas on how I can get
this ball rolling, I'd love to hear them!)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091002/5274f534/attachment.htm>
Received on Friday, 2 October 2009 15:07:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:17 UTC