On Wed, Nov 4, 2009 at 6:51 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</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;">
<div class="gmail_quote">That's correct.  My point is simple:  Here is another case where nesting can happen that hadn't been foreseen.  Trying to foresee all such issues is difficult.</div></blockquote><div><br>Yes.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>
Will we just keep amending the spec each time we find such a possible case?</div></div></blockquote><div><br>I would.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">OK, but my point is that the spec should afford implementors with the ability to unlock the storage mutex at other times for reasons not mentioned in the spec.</div></blockquote><div><br>I disagree, because this gives implementors freedom to drop the mutex in situations that might really just be fixable implementation bugs. I think our positions are clear now so we'll just have to agree to disagree.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="gmail_quote"><div><br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">I'm not convinced.  Look at Google Maps and street view.  Gmail uses more Flash now than it used to. </div></blockquote></div><div><br>For new features, sure. But are they reimplementing existing browser-based functionality to use plugins instead?<br>

</div></div></blockquote><div><br></div></div><div>I think it is sufficient to just talk in the context of new features.  A JS library or component grows a new feature that suddenly starts using a plugin.  Now, API calls that were not supposed to touch plugins start touching plugins, and the storage mutex gets dropped.</div>
</div></blockquote><div><br>That only matters if they start using the new feature in the middle of a localStorage "transaction". That seems possible, but unlikely, to me.<br><br></div>Rob<br></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>