[whatwg] Structured clone algorithm on LocalStorage
Jonas Sicking
jonas at sicking.cc
Fri Oct 2 21:47:51 PDT 2009
On Fri, Oct 2, 2009 at 9:11 PM, Darin Fisher <darin at chromium.org> wrote:
> >> It still seems to me that it's extremely unlikely that pages depend on
>>>> >> cross origin events to fire synchronously. I can't even think of a
>>>> way
>>>> >> to test if a browser dispatches these events synchronously or not.
>>>> Can
>>>> >> you?
>>>> >
>>>> > i agree that it seems uncommon. maybe there could be some odd app
>>>> that
>>>> > does something after resizing an iframe that could be dependent on the
>>>> > event handler setting some data field. this kind of thing is probably
>>>> even
>>>> > less common in the cross-origin case.
>>>>
>>>> But how would you read that data field in the cross-origin frame? I
>>>> think it might be possible, but extremely hard.
>>>>
>>>>
>>> Yeah.
>>>
>>> My concern is simply that I cannot prove that I don't have to worry about
>>> this
>>> problem. Future web APIs might also inadvertently make matters worse.
>>>
>>
>> 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.
>>
>
> Agreed. That's a good point. In that case, I was concerned about stack
> depth. The same issue might apply here. Hmm...
>
As far as I can see it does.
> > ripping off database:
>>>> > interface ValueStorage {
>>>> > void transaction(in DOMString namespace, in
>>>> > ValueStorageTransactionCallback callback);
>>>> > };
>>>> > interface ValueStorageTransactionCallback {
>>>> > void handleEvent(in ValueStorageTransaction transaction);
>>>> > };
>>>> > interface ValueStorageTransaction {
>>>> > void readValue(in DOMString name, in ValueStorageReadCallback
>>>> callback);
>>>> > void writeValue(in DOMString name, in DOMString value);
>>>> > };
>>>> > interface ValueStorageReadCallback {
>>>> > void handleEvent(in ValueStorageTransaction transaction, in
>>>> DOMString
>>>> > value);
>>>> > };
>>>> > then, to use these interfaces, you could implement thread-safe
>>>> increment:
>>>> > window.localStorage.transaction("slice", function(transaction) {
>>>> > transaction.readValue("foo", function(transaction, fooValue) {
>>>> > transaction.writeValue("foo", ++fooValue);
>>>> > })
>>>> > })
>>>> > to fetch multiple values, you could do this:
>>>> > var values = [];
>>>> > var numValues = 10;
>>>> > function readNextValue(transaction) {
>>>> > if (values.length == numValues)
>>>> > return; // done!
>>>> > var index = values.length;
>>>> > transaction.readValue("value" + index, function(transaction, value)
>>>> {
>>>> > values.push(value);
>>>> > readNextValue(transaction);
>>>> > })
>>>> > }
>>>> > window.localStorage.transaction("slice", readNextValue);
>>>> > This has the property that all IO is non-blocking and the "lock" is
>>>> held
>>>> > only
>>>> > for a very limited scope. The programmer is however free to extend
>>>> the
>>>> > life of the lock as needed.
>>>>
>>>> What do you mean by that the "lock" is held for only a very limited
>>>> scope? You still want to prevent modifications for as long as the
>>>> transaction is being used right? I.e. no modifications can happen
>>>> between the read and the write in the first example, and between the
>>>> different reads in the second.
>>>>
>>>
>>> Yes. I only meant that the programmer doesn't have to call a special
>>> function to close the transaction. It closes by virtue of the last
>>> handleEvent
>>> call referring to the transaction returning.
>>>
>>
>> So wouldn't you implement this transaction using a lock? To prevent other
>> pages from accessing the localStorage?
>>
>>
> 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.
>
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.
/ Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091002/fb4098fc/attachment-0002.htm>
More information about the whatwg
mailing list