On Fri, Oct 2, 2009 at 9:11 PM, 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"><div><div class="h5"><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><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><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div>
>> It still seems to me that it's extremely unlikely that pages depend on<br>
>> cross origin events to fire synchronously. I can't even think of a way<br>
>> to test if a browser dispatches these events synchronously or not. Can<br>
>> you?<br>
><br>
> i agree that it seems uncommon. maybe there could be some odd app that<br>
> does something after resizing an iframe that could be dependent on the<br>
> event handler setting some data field. this kind of thing is probably even<br>
> less common in the cross-origin case.<br>
<br>
</div></div>But how would you read that data field in the cross-origin frame? I<br>
think it might be possible, but extremely hard.<br>
<div><div></div><div><br></div></div></blockquote><div><br></div></div></div><div>Yeah.</div><div><br></div><div>My concern is simply that I cannot prove that I don't have to worry about this</div><div>problem. Future web APIs might also inadvertently make matters worse.</div>
</div></blockquote></div></div><div><br>I agree it's not ideal, but at the same time I don't think that not allowing synchronous cross-origin APIs is a huge burden. You campaigned heavily against that when we were designing postMessage for wholly other reasons. I would imagine those reasons will hole true no matter what.<br>
</div></div></blockquote><div><br></div></div></div><div>Agreed. That's a good point. In that case, I was concerned about stack depth. The same issue might apply here. Hmm...</div></div></blockquote><div><br>As far as I can see it does.<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><div class="h5"><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><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><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div>> ripping off database:<br>
> interface ValueStorage {<br>
> void transaction(in DOMString namespace, in<br>
> ValueStorageTransactionCallback callback);<br>
> };<br>
> interface ValueStorageTransactionCallback {<br>
> void handleEvent(in ValueStorageTransaction transaction);<br>
> };<br>
> interface ValueStorageTransaction {<br>
> void readValue(in DOMString name, in ValueStorageReadCallback callback);<br>
> void writeValue(in DOMString name, in DOMString value);<br>
> };<br>
> interface ValueStorageReadCallback {<br>
> void handleEvent(in ValueStorageTransaction transaction, in DOMString<br>
> value);<br>
> };<br>
> then, to use these interfaces, you could implement thread-safe increment:<br>
> window.localStorage.transaction("slice", function(transaction) {<br>
> transaction.readValue("foo", function(transaction, fooValue) {<br>
> transaction.writeValue("foo", ++fooValue);<br>
> })<br>
> })<br>
> to fetch multiple values, you could do this:<br>
> var values = [];<br>
> var numValues = 10;<br>
> function readNextValue(transaction) {<br>
> if (values.length == numValues)<br>
> return; // done!<br>
> var index = values.length;<br>
> transaction.readValue("value" + index, function(transaction, value) {<br>
> values.push(value);<br>
> readNextValue(transaction);<br>
> })<br>
> }<br>
> window.localStorage.transaction("slice", readNextValue);<br>
> This has the property that all IO is non-blocking and the "lock" is held<br>
> only<br>
> for a very limited scope. The programmer is however free to extend the<br>
> life of the lock as needed.<br>
<br>
</div></div>What do you mean by that the "lock" is held for only a very limited<br>
scope? You still want to prevent modifications for as long as the<br>
transaction is being used right? I.e. no modifications can happen<br>
between the read and the write in the first example, and between the<br>
different reads in the second.<br></blockquote><div><br></div></div></div><div>Yes. I only meant that the programmer doesn't have to call a special</div><div>function to close the transaction. It closes by virtue of the last handleEvent</div>
<div>call referring to the transaction returning.</div></div></blockquote></div></div><div><br>So wouldn't you implement this transaction using a lock? To prevent other pages from accessing the localStorage?<br><br></div>
</div></blockquote><div><br></div></div></div><div>Yes, but it wouldn't need to be a normal mutex if that's what you mean. You could just defer callbacks until the transaction completes. It is purely asynchronous locking.</div>
</div></blockquote><div><br>So how is that then different from from using a Storage API, but only
letting you get a reference to the Storage object using a asynchronous
API? And of course not allowing the Storage object to be stored in a
variable and used outside the callback.<br><br>/ Jonas<br></div></div>