<div class="gmail_quote">On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher <span dir="ltr">&lt;<a href="mailto:darin@chromium.org">darin@chromium.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div><div></div><div class="h5">On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking <span dir="ltr">&lt;jonas@sicking.cc&gt;</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>On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher &lt;<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking &lt;jonas@sicking.cc&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow &lt;<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>&gt; wrote:<br>
&gt;&gt; &gt; On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking &lt;jonas@sicking.cc&gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon &lt;<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt; On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow &lt;<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>&gt;<br>
&gt;&gt; &gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt;&gt; What are the use cases for wanting to store data beyond strings (and<br>
&gt;&gt; &gt;&gt; &gt;&gt; what<br>
&gt;&gt; &gt;&gt; &gt;&gt; can be serialized into strings) in LocalStorage?  I can&#39;t think of<br>
&gt;&gt; &gt;&gt; &gt;&gt; any<br>
&gt;&gt; &gt;&gt; &gt;&gt; that<br>
&gt;&gt; &gt;&gt; &gt;&gt; outweigh the negatives:<br>
&gt;&gt; &gt;&gt; &gt;&gt; 1)  From previous threads, I think it&#39;s fair to say that we can all<br>
&gt;&gt; &gt;&gt; &gt;&gt; agreed<br>
&gt;&gt; &gt;&gt; &gt;&gt; that LocalStorage is a regrettable API (mainly due to its<br>
&gt;&gt; &gt;&gt; &gt;&gt; synchronous<br>
&gt;&gt; &gt;&gt; &gt;&gt; nature).  If so, it seems that making it more powerful and thus more<br>
&gt;&gt; &gt;&gt; &gt;&gt; attractive to developers is just asking for trouble.  After all, the<br>
&gt;&gt; &gt;&gt; &gt;&gt; more<br>
&gt;&gt; &gt;&gt; &gt;&gt; people use it, the more lock contention there&#39;ll be, and the more<br>
&gt;&gt; &gt;&gt; &gt;&gt; browser UI<br>
&gt;&gt; &gt;&gt; &gt;&gt; jank users will be sure to experience.  This will also be worse<br>
&gt;&gt; &gt;&gt; &gt;&gt; because<br>
&gt;&gt; &gt;&gt; &gt;&gt; it&#39;ll be easier for developers to store large objects in<br>
&gt;&gt; &gt;&gt; &gt;&gt; LoaclStorage.<br>
&gt;&gt; &gt;&gt; &gt;&gt; 2)  As far as I can tell, there&#39;s no where else in the spec where<br>
&gt;&gt; &gt;&gt; &gt;&gt; you<br>
&gt;&gt; &gt;&gt; &gt;&gt; have<br>
&gt;&gt; &gt;&gt; &gt;&gt; to serialize structured clone(able) data to disk.  Given that<br>
&gt;&gt; &gt;&gt; &gt;&gt; LocalStorage<br>
&gt;&gt; &gt;&gt; &gt;&gt; is supposed to throw an exception if any ImageData is contained and<br>
&gt;&gt; &gt;&gt; &gt;&gt; since<br>
&gt;&gt; &gt;&gt; &gt;&gt; File and FileData objects are legal, it seems as though making<br>
&gt;&gt; &gt;&gt; &gt;&gt; LocalStorage<br>
&gt;&gt; &gt;&gt; &gt;&gt; handle structured clone data has a fairly high cost to implementors.<br>
&gt;&gt; &gt;&gt; &gt;&gt;  Not to<br>
&gt;&gt; &gt;&gt; &gt;&gt; mention that disallowing ImageData in only this one case is not<br>
&gt;&gt; &gt;&gt; &gt;&gt; intuitive.<br>
&gt;&gt; &gt;&gt; &gt;&gt; I think allowing structured clone(able) data in LocalStorage is a<br>
&gt;&gt; &gt;&gt; &gt;&gt; big<br>
&gt;&gt; &gt;&gt; &gt;&gt; mistake.  Enough so that, if SessionStorage and LocalStorage can&#39;t<br>
&gt;&gt; &gt;&gt; &gt;&gt; diverge<br>
&gt;&gt; &gt;&gt; &gt;&gt; on this issue, it&#39;d be worth taking the power away from<br>
&gt;&gt; &gt;&gt; &gt;&gt; SessionStorage.<br>
&gt;&gt; &gt;&gt; &gt;&gt; J<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; Speaking from experience, I have been using localStorage in my PhD<br>
&gt;&gt; &gt;&gt; &gt; thesis work w/o any real need for structured clones (I would have<br>
&gt;&gt; &gt;&gt; &gt; used<br>
&gt;&gt; &gt;&gt; &gt; Web Database but it isn&#39;t widely used yet and I was not sure if it<br>
&gt;&gt; &gt;&gt; &gt; was<br>
&gt;&gt; &gt;&gt; &gt; going to make the cut in the end). All it took to come close to<br>
&gt;&gt; &gt;&gt; &gt; simulating structured clones now was to develop my own compatibility<br>
&gt;&gt; &gt;&gt; &gt; wrapper for localStorage (<a href="http://realstorage.googlecode.com" target="_blank">http://realstorage.googlecode.com</a> for those<br>
&gt;&gt; &gt;&gt; &gt; who care) and add setJSONObject() and getJSONObject() methods on the<br>
&gt;&gt; &gt;&gt; &gt; wrapper. Works w/o issue.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Actually, this seems like a prime reason *to* add structured storage<br>
&gt;&gt; &gt;&gt; support. Obviously string data wasn&#39;t enough for you so you had to<br>
&gt;&gt; &gt;&gt; write extra code in order to work around that. If structured clones<br>
&gt;&gt; &gt;&gt; had been natively supported you both would have had to write less<br>
&gt;&gt; &gt;&gt; code, and the resulting algorithms would have been faster. Faster<br>
&gt;&gt; &gt;&gt; since the browser can serialize/parser to/from a binary internal<br>
&gt;&gt; &gt;&gt; format faster than to/from JSON through the JSON serializer/parser.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Yes, but since LocalStorage is already widely deployed, authors are<br>
&gt;&gt; &gt; stuck<br>
&gt;&gt; &gt; with the the structured clone-less version of LocalStorage for a very<br>
&gt;&gt; &gt; long<br>
&gt;&gt; &gt; time.  So the only way an app can store anything that can&#39;t be JSONified<br>
&gt;&gt; &gt; is<br>
&gt;&gt; &gt; to break backwards compatibility.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking &lt;jonas@sicking.cc&gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow &lt;<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>&gt;<br>
&gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt; &gt;&gt; &gt; What are the use cases for wanting to store data beyond strings (and<br>
&gt;&gt; &gt;&gt; &gt; what<br>
&gt;&gt; &gt;&gt; &gt; can be serialized into strings) in LocalStorage?  I can&#39;t think of<br>
&gt;&gt; &gt;&gt; &gt; any<br>
&gt;&gt; &gt;&gt; &gt; that<br>
&gt;&gt; &gt;&gt; &gt; outweigh the negatives:<br>
&gt;&gt; &gt;&gt; &gt; 1)  From previous threads, I think it&#39;s fair to say that we can all<br>
&gt;&gt; &gt;&gt; &gt; agreed<br>
&gt;&gt; &gt;&gt; &gt; that LocalStorage is a regrettable API (mainly due to its synchronous<br>
&gt;&gt; &gt;&gt; &gt; nature).  If so, it seems that making it more powerful and thus more<br>
&gt;&gt; &gt;&gt; &gt; attractive to developers is just asking for trouble.  After all, the<br>
&gt;&gt; &gt;&gt; &gt; more<br>
&gt;&gt; &gt;&gt; &gt; people use it, the more lock contention there&#39;ll be, and the more<br>
&gt;&gt; &gt;&gt; &gt; browser UI<br>
&gt;&gt; &gt;&gt; &gt; jank users will be sure to experience.  This will also be worse<br>
&gt;&gt; &gt;&gt; &gt; because<br>
&gt;&gt; &gt;&gt; &gt; it&#39;ll be easier for developers to store large objects in<br>
&gt;&gt; &gt;&gt; &gt; LoaclStorage.<br>
&gt;&gt; &gt;&gt; &gt; 2)  As far as I can tell, there&#39;s no where else in the spec where you<br>
&gt;&gt; &gt;&gt; &gt; have<br>
&gt;&gt; &gt;&gt; &gt; to serialize structured clone(able) data to disk.  Given that<br>
&gt;&gt; &gt;&gt; &gt; LocalStorage<br>
&gt;&gt; &gt;&gt; &gt; is supposed to throw an exception if any ImageData is contained and<br>
&gt;&gt; &gt;&gt; &gt; since<br>
&gt;&gt; &gt;&gt; &gt; File and FileData objects are legal, it seems as though making<br>
&gt;&gt; &gt;&gt; &gt; LocalStorage<br>
&gt;&gt; &gt;&gt; &gt; handle structured clone data has a fairly high cost to implementors.<br>
&gt;&gt; &gt;&gt; &gt;  Not to<br>
&gt;&gt; &gt;&gt; &gt; mention that disallowing ImageData in only this one case is not<br>
&gt;&gt; &gt;&gt; &gt; intuitive.<br>
&gt;&gt; &gt;&gt; &gt; I think allowing structured clone(able) data in LocalStorage is a big<br>
&gt;&gt; &gt;&gt; &gt; mistake.  Enough so that, if SessionStorage and LocalStorage can&#39;t<br>
&gt;&gt; &gt;&gt; &gt; diverge<br>
&gt;&gt; &gt;&gt; &gt; on this issue, it&#39;d be worth taking the power away from<br>
&gt;&gt; &gt;&gt; &gt; SessionStorage.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Despite localStorage unfortunate locking contention problem, it&#39;s<br>
&gt;&gt; &gt;&gt; become quite a popular API. It&#39;s also very successful in terms of<br>
&gt;&gt; &gt;&gt; browser deployment since it&#39;s available in at least latest versions of<br>
&gt;&gt; &gt;&gt; IE, Safari, Firefox, and Chrome. Don&#39;t know about support in Opera?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The more popular it becomes, the more it&#39;s going to hurt UA developers,<br>
&gt;&gt; &gt; web<br>
&gt;&gt; &gt; developers, and users.  I don&#39;t see why this is an argument for making<br>
&gt;&gt; &gt; it<br>
&gt;&gt; &gt; more powerful.<br>
&gt;&gt;<br>
&gt;&gt; How will it hurt UA developers? I think we&#39;re stuck forever to<br>
&gt;&gt; implement the locking mechanism. Adding more datatypes to the API<br>
&gt;&gt; doesn&#39;t mean that we&#39;ll have to implement it more.<br>
&gt;<br>
&gt;<br>
&gt; multi-core is the future.  what&#39;s the opposite of fine-grained locking?<br>
&gt;  it&#39;s not good ;-)<br>
&gt; the implicit locking mechanism as spec&#39;d is super lame.  implicitly<br>
&gt; unlocking under<br>
&gt; mysterious-to-the-developer circumstances!  how can that be a good thing?<br>
&gt; storage.setItem(&quot;y&quot;,<br>
&gt; function_involving_implicit_unlocking(storage.getItem(&quot;x&quot;)));<br>
<br>
</div></div>I totally agree on all points. The current API has big imperfections.<br>
However I haven&#39;t seen any workable counter proposals so far, and I<br>
honestly don&#39;t believe there are any as long as our goals are:<br>
<br>
* Don&#39;t break existing users of the current implementations.<br>
* Don&#39;t expose race conditions to the web.<br>
* Don&#39;t rely on authors getting explicit locking mechanisms right.<br>
<br></blockquote><div><br></div></div></div><div>The current API exposes race conditions to the web.  The implicit</div><div>dropping of the storage lock is that.  In Chrome, we&#39;ll have to drop</div><div>an existing lock whenever a new lock is acquired.  That can happen</div>

<div>due to a variety of really odd cases (usually related to nested loops</div><div>or nested JS execution), which will be difficult for developers to</div><div>predict, especially if they are relying on third-party JS libraries.</div>

<div><br></div><div>This issue seems to be discounted for reasons I do not understand.</div><div><div></div><div class="h5"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


But, as imperfect as the current API is, I think the following is a<br>
decent way forward:<br>
<br>
* Allow pages that want the convenience of localStorage to use it. For<br>
multi-process browsers this will mean poor UI *for pages that use<br>
localStorage*. Especially when said pages hold on to localStorage for<br>
a long time.<br>
* Add alternative APIs that don&#39;t suffer from the same problems. More below.<br>
<div><div></div><div><br>
&gt;&gt; &gt; In addition, this argument assumes that Microsoft (and other UAs) will<br>
&gt;&gt; &gt; implement the structured clone version of LocalStorage.  Has anyone (or<br>
&gt;&gt; &gt; can<br>
&gt;&gt; &gt; anyone) from Microsoft comment on this?<br>
&gt;&gt;<br>
&gt;&gt; Given that I&#39;ve never heard microsoft commit to a webstandard, ever, I<br>
&gt;&gt; doubt that we&#39;ll hear anything here. Or that the lack of hearing<br>
&gt;&gt; anything means we can draw any conclusions.<br>
&gt;&gt;<br>
&gt;&gt; &gt; This is not a small feature to add.  Yes, it&#39;s smaller than creating a<br>
&gt;&gt; &gt; new<br>
&gt;&gt; &gt; storage mechanism (that everyone is willing to adopt), but I still think<br>
&gt;&gt; &gt; that&#39;s what we should be looking at.  Rather than polishing a turd.<br>
&gt;&gt;<br>
&gt;&gt; I do think that localStorage is a decent API that developers will want<br>
&gt;&gt; to, and should, use. I think looking into adding a async accessor to<br>
&gt;&gt; get a storage object so that people can use an localStorage-like API<br>
&gt;&gt; while avoiding risks of blocking. This would also allow sharing data<br>
&gt;&gt; between worker threads and the main window.<br>
&gt;<br>
&gt; i think the async callback to get a storage object is an improvement, but<br>
&gt; i&#39;m not sure that it addresses all of the problems.  for example, if a<br>
&gt; worker<br>
&gt; wants to read values from storage, compute, and then put a value into<br>
&gt; storage, it would probably do all of this from the storage callback.  that<br>
&gt; would result in holding the lock for a long time, which would lock out any<br>
&gt; other threads, including non-worker threads.<br>
&gt; the problem here is that localStorage is a pile of global variables.  we are<br>
&gt; trying to give people global variables without giving them tools to<br>
&gt; synchronize<br>
&gt; access to them.  the claim i&#39;ve heard is that developers are not savy enough<br>
&gt; to use those tools properly.  i agree that developers tend to use tools<br>
&gt; without<br>
&gt; fully understanding them.  ok, but then why are we giving them global<br>
&gt; variables?<br>
&gt; there has to be a better answer.<br>
<br>
</div></div>I actually described an potential solution in the thread on worker storage.<br>
<br>
The problem you describe is a worker holding on the the storage for an<br>
very long (indefinite) time, thereby locking out other threads/windows<br>
from accessing the same storage area. This seems inevitable if we want<br>
to prevent race conditions while at the same time not forcing the<br>
complexities of locks onto web developers. The WebDatabase API suffers<br>
from exactly the same problem.<br></blockquote><div><br></div></div></div><div>Hmm... are you saying that from the SQLStatementCallback used to read</div><div>some data out of the database, you might compute on that data, and then</div>

<div>issue an executeSql call to write a computed result, and that in this scenario,</div><div>the fact that it is the same transaction means that other threads are locked</div><div>out of accessing the same database?  I hadn&#39;t considered chaining executeSql</div>

<div>calls like this to keep the transaction alive.  Hmm...</div><div><div></div><div class="h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
However, we can lessen the problem. By adding multiple storage areas,<br>
we can allow a worker to use one storage area, while allowing other<br>
parties to simultaneously use other storage areas. This way, if a<br>
worker and a window aren&#39;t sharing data at all, they never get in the<br>
way of each other.<br>
<br>
So a very simplistic design would be something like the following:<br>
<br>
getStorageArea(name, callback)<br>
<br>
when called will asynchronously call the callback parameter once the<br>
storage area named by the first parameter becomes available. The<br>
callback receives the storage area as an argument. We would also have<br>
the function<br>
<br>
getMultipleStorageAreas(names, callback)<br>
<br>
Same as above, but names is an array of strings indicating multiple<br>
storage areas that need to be acquired before the callback is called.<br>
The callback receives all the areas in an array as an argument. This<br>
function allows transferring data between multiple storage areas<br>
without risking racing.<br>
<br>
There&#39;s several problems with this, such as the names are sort of<br>
crappy, and that getting storage areas an array isn&#39;t very friendly.<br>
However you get the basic idea.<br>
<br>
We don&#39;t even need to use Storage objects for this. In fact, I hope<br>
mozilla will in a not too distant future come up with an alternative<br>
proposal to the WebDatabase SQL API. Something like this might fit<br>
into such a proposal as I think that&#39;ll have multiple separate storage<br>
areas anyway.<br>
<font color="#888888"><br>
/ Jonas<br>
</font></blockquote></div></div></div><br><div><br></div><div>Maybe we should just invent a similar transaction method for name/value</div><div>storage?  Wouldn&#39;t that be better than inventing a new idiom?  Ideally,</div>
<div>we&#39;d also make reads and writes on storage be asynchronous.  The</div>
<div>transaction would then be usable to hold the lock across multiple</div><div>asynchronous reads and writes.  Since local storage is backed by disk,</div><div>it seems like a more ideal local storage API would not require synchronous</div>

<div>filesystem access.</div><div><br></div><font color="#888888"><div>-Darin</div>
</font></blockquote></div><br><div><br></div><div>I forgot to say that I like the name proposal.  It gives domains a way to</div><div>carve up their storage, avoiding the need to create dummy hostnames.</div><div><br></div>
<div>-Darin</div>