<div class="gmail_quote">On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
>> What are the use cases for wanting to store data beyond strings (and what<br>
>> can be serialized into strings) in LocalStorage?  I can't think of any that<br>
>> outweigh the negatives:<br>
>> 1)  From previous threads, I think it's fair to say that we can all agreed<br>
>> that LocalStorage is a regrettable API (mainly due to its synchronous<br>
>> nature).  If so, it seems that making it more powerful and thus more<br>
>> attractive to developers is just asking for trouble.  After all, the more<br>
>> people use it, the more lock contention there'll be, and the more browser UI<br>
>> jank users will be sure to experience.  This will also be worse because<br>
>> it'll be easier for developers to store large objects in LoaclStorage.<br>
>> 2)  As far as I can tell, there's no where else in the spec where you have<br>
>> to serialize structured clone(able) data to disk.  Given that LocalStorage<br>
>> is supposed to throw an exception if any ImageData is contained and since<br>
>> File and FileData objects are legal, it seems as though making LocalStorage<br>
>> handle structured clone data has a fairly high cost to implementors.  Not to<br>
>> mention that disallowing ImageData in only this one case is not intuitive.<br>
>> I think allowing structured clone(able) data in LocalStorage is a big<br>
>> mistake.  Enough so that, if SessionStorage and LocalStorage can't diverge<br>
>> on this issue, it'd be worth taking the power away from SessionStorage.<br>
>> J<br>
><br>
> Speaking from experience, I have been using localStorage in my PhD<br>
> thesis work w/o any real need for structured clones (I would have used<br>
> Web Database but it isn't widely used yet and I was not sure if it was<br>
> going to make the cut in the end). All it took to come close to<br>
> simulating structured clones now was to develop my own compatibility<br>
> wrapper for localStorage (<a href="http://realstorage.googlecode.com" target="_blank">http://realstorage.googlecode.com</a> for those<br>
> who care) and add setJSONObject() and getJSONObject() methods on the<br>
> wrapper. Works w/o issue.<br>
<br>
</div></div>Actually, this seems like a prime reason *to* add structured storage<br>
support. Obviously string data wasn't enough for you so you had to<br>
write extra code in order to work around that. If structured clones<br>
had been natively supported you both would have had to write less<br>
code, and the resulting algorithms would have been faster. Faster<br>
since the browser can serialize/parser to/from a binary internal<br>
format faster than to/from JSON through the JSON serializer/parser.</blockquote><div><br></div><div>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.</div>

<div><br></div><div><br></div><div><br><br><div class="gmail_quote">On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

<div><div></div><div class="h5">On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>> What are the use cases for wanting to store data beyond strings (and what<br>

> can be serialized into strings) in LocalStorage?  I can't think of any that<br>> outweigh the negatives:<br>> 1)  From previous threads, I think it's fair to say that we can all agreed<br>> that LocalStorage is a regrettable API (mainly due to its synchronous<br>

> nature).  If so, it seems that making it more powerful and thus more<br>> attractive to developers is just asking for trouble.  After all, the more<br>> people use it, the more lock contention there'll be, and the more browser UI<br>

> jank users will be sure to experience.  This will also be worse because<br>> it'll be easier for developers to store large objects in LoaclStorage.<br>> 2)  As far as I can tell, there's no where else in the spec where you have<br>

> to serialize structured clone(able) data to disk.  Given that LocalStorage<br>> is supposed to throw an exception if any ImageData is contained and since<br>> File and FileData objects are legal, it seems as though making LocalStorage<br>

> handle structured clone data has a fairly high cost to implementors.  Not to<br>> mention that disallowing ImageData in only this one case is not intuitive.<br>> I think allowing structured clone(able) data in LocalStorage is a big<br>

> mistake.  Enough so that, if SessionStorage and LocalStorage can't diverge<br>> on this issue, it'd be worth taking the power away from SessionStorage.<br><br></div></div>Despite localStorage unfortunate locking contention problem, it's<br>

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

</blockquote><div><br></div><div>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.</div><div><br>
</div>
<div>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?</div><div><br></div><div>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.</div>

</div></div></div>