[whatwg] Structured clone algorithm on LocalStorage

[Brett Cannon]

On Wed, Sep 23, 2009 at 13:35, 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.
> J

Speaking from experience, I have been using localStorage in my PhD
thesis work w/o any real need for structured clones (I would have used
Web Database but it isn't widely used yet and I was not sure if it was
going to make the cut in the end). All it took to come close to
simulating structured clones now was to develop my own compatibility
wrapper for localStorage (http://realstorage.googlecode.com for those
who care) and add setJSONObject() and getJSONObject() methods on the
wrapper. Works w/o issue.

Actually, there is a third drawback to the structured clones, which is
creating a backwards-compatible layer for existing browsers to
simulate structured clones will probably be hard. Since JSON does not
cover the new object types being introduced in HTML5 you will most
likely have to stringify all the file types some how, prefix a type to
the JSON string, and then on getItem() parse the string.

But the constructor for all the types covered by the structured clone
algorithm will not let you create a perfect copy. Take RegExp; the
structured clone spec says you get to skip lastIndex. OK, but what
about constructing a RegExp object with the proper input, lastMatch,
lastParen, etc.? Would a wrapper have to re-execute the search on the
RegExp to fast-forward to the proper state of the stored object? That
sounds painful.

If you all are regretting localStorage already even though it's
deployed using strings on most browsers (I think Opera doesn't have
it?), I would agree with Jeremy that perhaps this part of the spec
should just be considered "dead" and not fiddled with to try to
improve it.

-Brett