I'd like to propose a way forward. Please have an open mind.<div><br></div><div>The objections your hearing from the chrome world are around the locking semantics being proposed. In various discussions the terms "evil", "troubling", and "onerous" have been used to describe what we think about aspects of those semantics. There are obvious difficulties in providing the semantics being discussed in a multi-threaded multi-process browser. There are obvious performance implications. There are limitations imposed on workers that would otherwise not be an issue. And with the introduction of these locks today, there would be challenges going forward when trying to add new features such that deadlocks would not be incurred... our hands would be getting tied up. So we don't like it... evil, troubling, onerous.</div>
<div><br></div><div>The objections I'm hearing from the firefox world are around providing an API that is less error prone.</div><div><br></div><div>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>
<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><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><div><br></div><div><br></div><div><br></div><div><br><br></div>