[whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon <brett at python.org> wrote:
>> > 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, this seems like a prime reason *to* add structured storage
>> support. Obviously string data wasn't enough for you so you had to
>> write extra code in order to work around that. If structured clones
>> had been natively supported you both would have had to write less
>> code, and the resulting algorithms would have been faster. Faster
>> since the browser can serialize/parser to/from a binary internal
>> format faster than to/from JSON through the JSON serializer/parser.
>
> Yes, but since LocalStorage is already widely deployed, authors are stuck
> with the the structured clone-less version of LocalStorage for a very long
> time.  So the only way an app can store anything that can't be JSONified is
> to break backwards compatibility.
>
>
>
> On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> 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?
>
> The more popular it becomes, the more it's going to hurt UA developers, web
> developers, and users.  I don't see why this is an argument for making it
> more powerful.

How will it hurt UA developers? I think we're stuck forever to
implement the locking mechanism. Adding more datatypes to the API
doesn't mean that we'll have to implement it more.

> In addition, this argument assumes that Microsoft (and other UAs) will
> implement the structured clone version of LocalStorage.  Has anyone (or can
> anyone) from Microsoft comment on this?

Given that I've never heard microsoft commit to a webstandard, ever, I
doubt that we'll hear anything here. Or that the lack of hearing
anything means we can draw any conclusions.

> This is not a small feature to add.  Yes, it's smaller than creating a new
> storage mechanism (that everyone is willing to adopt), but I still think
> that's what we should be looking at.  Rather than polishing a turd.

I do think that localStorage is a decent API that developers will want
to, and should, use. I think looking into adding a async accessor to
get a storage object so that people can use an localStorage-like API
while avoiding risks of blocking. This would also allow sharing data
between worker threads and the main window.

/ Jonas