On Thu, Apr 2, 2009 at 7:18 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I suggest that we can come up with a design that makes both of these camps happy and that should be our goal here.
<div><br></div><div>To that end... what if...</div><div><br></div><div>interface Store {</div><div>  void putItem(string name, string value);</div><div>  </div><div>  string getItem(string name); </div><div>  // calling getItem multiple times prior to script completion with the same name is gauranteed to return the same value</div>

<div>  // (unless the current script had called putItem, if a different script had called putItem concurrently, the current script wont see that)</div><div><br></div><div>  void transact(func transactCallback);</div><div>

  // is not guaranteed to execute if the page is unloaded prior to the lock being acquired</div><div>  // is guaranteed to NOT execute if called from within onunload</div><div>  // but... really... if you need transactional semantics, maybe you should be using a Database?</div>

<div><br></div><div>  attribute int length;</div><div>  // may only be accessed within a transactCallback, othewise throws an exception</div><div>  </div><div>  string getItemByIndex(int i);</div><div>  // // may only be accessed within a transactCallback, othewise throws an exception</div>

<div>};</div></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div></div><div><br></div><div><br></div><div>document.cookie;</div>
<div>// has the same safe to read multiple times semantics as store.getItem()</div><div><br></div><div><br></div><div>So there are no locking semantics (outside of the transact method)... and multiple reads are not error prone.</div>

<div><br></div><div>WDYT?</div></blockquote><div><br>getItem stability is helpful for read-only scripts but no help for read-write scripts. For example, outside a transaction, two scripts doing putItem('x', getItem('x') + 1) can race and lose an increment. Even for read-only scripts, you have the problem that reading multiple values isn't guaranteed to give you a consistent state. So this isn't much better than doing nothing for the default case. (Note that you can provide hen read-only scripts are easy to optimize for full parallelism using ) Forcing iteration to be inside a transaction isn't compatible with existing localStorage either.<br>
<br>Addressing the larger context ... More than anything else, I'm channeling my experiences at IBM Research writing race detection tools for Java programs ( <a href="http://portal.acm.org/citation.cfm?id=781528">http://portal.acm.org/citation.cfm?id=781528</a> and others), and what I learned there about programmers with a range of skill levels grappling with shared memory (or in our case, shared storage) concurrency. I passionately, violently believe that Web programmers cannot and should not have to deal with it. It's simply a matter of implementing what programmers expect: that by default, a chunk of sequential code will do what it says without (occasional, random) interference from outside.<br>
<br>I realize that this creates major implementation difficulties for parallel browsers, which I believe will be all browsers. "Evil', "troubling" and "onerous" are perhaps understatements... But it will be far better in the long run to put those burdens on browser developers than to kick them upstairs to Web developers. If it turns out that there is a compelling performance boost that can *only* be achieved by relaxing serializability, then I could be convinced ... but we are very far from proving that.<br>
<br>Rob <br></div></div>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>