<br><br><div class="gmail_quote">On Wed, Sep 23, 2009 at 8:10 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 3:29 PM, Jeremy Orlow <<a href="mailto:jorlow@chromium.org">jorlow@chromium.org</a>> wrote:<br>
> On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking <jonas@sicking.cc> wrote:<br>
>><br>
>> 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<br>
>> >> what<br>
>> >> can be serialized into strings) in LocalStorage? I can't think of any<br>
>> >> that<br>
>> >> outweigh the negatives:<br>
>> >> 1) From previous threads, I think it's fair to say that we can all<br>
>> >> 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<br>
>> >> more<br>
>> >> people use it, the more lock contention there'll be, and the more<br>
>> >> 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<br>
>> >> have<br>
>> >> to serialize structured clone(able) data to disk. Given that<br>
>> >> LocalStorage<br>
>> >> is supposed to throw an exception if any ImageData is contained and<br>
>> >> since<br>
>> >> File and FileData objects are legal, it seems as though making<br>
>> >> LocalStorage<br>
>> >> handle structured clone data has a fairly high cost to implementors.<br>
>> >> Not to<br>
>> >> mention that disallowing ImageData in only this one case is not<br>
>> >> 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<br>
>> >> 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>
>> 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.<br>
><br>
> Yes, but since LocalStorage is already widely deployed, authors are stuck<br>
> with the the structured clone-less version of LocalStorage for a very long<br>
> time. So the only way an app can store anything that can't be JSONified is<br>
> to break backwards compatibility.<br>
><br>
><br>
><br>
> On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking <jonas@sicking.cc> wrote:<br>
>><br>
>> 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<br>
>> > what<br>
>> > can be serialized into strings) in LocalStorage? I can't think of any<br>
>> > that<br>
>> > outweigh the negatives:<br>
>> > 1) From previous threads, I think it's fair to say that we can all<br>
>> > 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<br>
>> > more<br>
>> > people use it, the more lock contention there'll be, and the more<br>
>> > 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<br>
>> > have<br>
>> > to serialize structured clone(able) data to disk. Given that<br>
>> > LocalStorage<br>
>> > is supposed to throw an exception if any ImageData is contained and<br>
>> > since<br>
>> > File and FileData objects are legal, it seems as though making<br>
>> > LocalStorage<br>
>> > handle structured clone data has a fairly high cost to implementors.<br>
>> > Not to<br>
>> > mention that disallowing ImageData in only this one case is not<br>
>> > 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<br>
>> > diverge<br>
>> > on this issue, it'd be worth taking the power away from SessionStorage.<br>
>><br>
>> 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>
><br>
> The more popular it becomes, the more it's going to hurt UA developers, web<br>
> developers, and users. I don't see why this is an argument for making it<br>
> more powerful.<br>
<br>
</div></div>How will it hurt UA developers? I think we're stuck forever to<br>
implement the locking mechanism. Adding more datatypes to the API<br>
doesn't mean that we'll have to implement it more.<br></blockquote><div><br></div><div><br></div><div>multi-core is the future. what's the opposite of fine-grained locking? it's not good ;-)</div><div><br>
</div><div>the implicit locking mechanism as spec'd is super lame. implicitly unlocking under</div><div>mysterious-to-the-developer circumstances! how can that be a good thing?</div><div><br></div><div>storage.setItem("y", function_involving_implicit_unlocking(storage.getItem("x")));</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> In addition, this argument assumes that Microsoft (and other UAs) will<br>
> implement the structured clone version of LocalStorage. Has anyone (or can<br>
> anyone) from Microsoft comment on this?<br>
<br>
</div>Given that I've never heard microsoft commit to a webstandard, ever, I<br>
doubt that we'll hear anything here. Or that the lack of hearing<br>
anything means we can draw any conclusions.<br>
<div class="im"><br>
> This is not a small feature to add. Yes, it's smaller than creating a new<br>
> storage mechanism (that everyone is willing to adopt), but I still think<br>
> that's what we should be looking at. Rather than polishing a turd.<br>
<br>
</div>I do think that localStorage is a decent API that developers will want<br>
to, and should, use. I think looking into adding a async accessor to<br>
get a storage object so that people can use an localStorage-like API<br>
while avoiding risks of blocking. This would also allow sharing data<br>
between worker threads and the main window.<br></blockquote><div><br></div><div>i think the async callback to get a storage object is an improvement, but</div><div>i'm not sure that it addresses all of the problems. for example, if a worker</div>
<div>wants to read values from storage, compute, and then put a value into</div><div>storage, it would probably do all of this from the storage callback. that</div><div>would result in holding the lock for a long time, which would lock out any</div>
<div>other threads, including non-worker threads.</div><div><br></div><div>the problem here is that localStorage is a pile of global variables. we are</div><div>trying to give people global variables without giving them tools to synchronize</div>
<div>access to them. the claim i've heard is that developers are not savy enough</div><div>to use those tools properly. i agree that developers tend to use tools without</div><div>fully understanding them. ok, but then why are we giving them global variables?</div>
<div><br></div><div>there has to be a better answer.</div><div><br></div><div>-darin</div></div>