Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Fri, Oct 2, 2009 at 9:58 PM, Darin Fisher da...@chromium.org wrote:

 Not quite sure I follow your proposal. How would you for example
   increase the value of a property by one without risking race
   conditions? Or keep two values in different properties in sync?
 I.e.
   so that if you update one always update the other, so that they
 never
   have different values.
  
   / Jonas
  
  
   Easy.  Just like with database, the transaction is the storage
 lock.
Any
   storage
   operation performed on that transaction are done atomically.
  However,
   all
   storage
   operations are asynchronous.  You basically string together
 asynchronous
   storage
   operations by using the same transaction for each.
   We could add methods to get/set multiple items at once to
 simplify life
   for
   the coder.
 
  I think I still don't understand your proposal, could you give some
  code examples?
 
 
 
  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.


 The difference is that storage IO is fully asynchronous in the API I
 proposed.  It doesn't have to block the calling thread for reads.  I think
 that is important.

 We should never design any APIs that involve synchronous IO (filesystem or
 network) from the main UI thread.


Ah, that's a different problem from what I thought you talked about
initially.

I wasn't part of the initial design-phase of this API. But as I understand
it, the idea was that it's expected that people will store small enough
amounts of information in localStorage that the database can be kept in
memory. Behind the scenes you can always write to disc asynchronously in
order to reduce risk of dataloss in case of crash.

I'm not sure if this is practical or not. I suspect that many times it won't
be. However even here a asynchronous getter would help since you can read in
the full database into memory at that point.

/ Jonas

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Fri, Oct 2, 2009 at 8:08 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 30, 2009 at 10:11 PM, Darin Fisher da...@chromium.org wrote:

 On Tue, Sep 29, 2009 at 11:48 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Tue, Sep 29, 2009 at 12:19 AM, Darin Fisher da...@chromium.org
 wrote:
  On Thu, Sep 24, 2009 at 11:57 PM, Jonas Sicking jo...@sicking.cc
 wrote:
 
  On Thu, Sep 24, 2009 at 9:04 PM, Darin Fisher da...@chromium.org
 wrote:
   On Thu, Sep 24, 2009 at 4:43 PM, Jonas Sicking jo...@sicking.cc
 wrote:
  
   On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher da...@chromium.org
 
   wrote:
On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking jo...@sicking.cc
 
wrote:
   
On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher 
 da...@chromium.org
wrote:
 On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking
 jo...@sicking.cc
 wrote:

 On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher
 da...@chromium.org
 wrote:
 
  ... snip ...
 
 
  multi-core is the future.  what's the opposite of
 fine-grained
  locking?
   it's not good ;-)
  the implicit locking mechanism as spec'd is super lame.
   implicitly
  unlocking under
  mysterious-to-the-developer circumstances!  how can that be
 a
  good
  thing?
  storage.setItem(y,
 
 function_involving_implicit_unlocking(storage.getItem(x)));

 I totally agree on all points. The current API has big
 imperfections.
 However I haven't seen any workable counter proposals so far,
 and
 I
 honestly don't believe there are any as long as our goals
 are:

 * Don't break existing users of the current implementations.
 * Don't expose race conditions to the web.
 * Don't rely on authors getting explicit locking mechanisms
 right.


 The current API exposes race conditions to the web.  The
 implicit
 dropping of the storage lock is that.  In Chrome, we'll have
 to
 drop
 an existing lock whenever a new lock is acquired.  That can
 happen
 due to a variety of really odd cases (usually related to
 nested
 loops
 or nested JS execution), which will be difficult for
 developers to
 predict, especially if they are relying on third-party JS
 libraries.
 This issue seems to be discounted for reasons I do not
 understand.
   
I don't believe we've heard about this before, so that would be
 the
reason it hasn't been taken into account.
   
So you're saying that chrome would be unable implement the
 current
storage mutex as specified in spec? I.e. one that is only
 released
at
the explicit points that the spec defines? That seems like a
 huge
problem.
   
No, no... my point is that to the application developer, those
explicit
points will appear quite implicit and mysterious.  This is why I
called
out third-party JS libraries.  One day, a function that you are
 using
might transition to scripting a plugin, which might cause a
 nested
loop, which could then force the lock to be released.  As a
programmer,
the unlocking is not explicit or predictable.
  
   Ah, indeed, this is a problem. However the unfortunate fact remains
   that so far no other workable solution has been proposed.
  
   OK, so we agree that the current solution doesn't meet the goals you
   stated above :-(
 
  Well, it addresses them as long as users are aware of the risk, and
  properly document weather their various library functions will release
  the lock or not. However I agree that it's unlikely that they will do
  so correctly.
 
  I thought the point of not having lock APIs was that users shouldn't
 have
  to understand locks ;-)  The issue I've raised here is super subtle.
  We
  have not succeeded in avoiding subtlety!

 I think we're mostly in agreement. What I'm not sure about is what you
 are proposing we do with localStorage? Remove it from the spec? Change
 the API? Something else?


 I'm glad we agree.

 I'm not sure what we should do.  It seems like there is a legacy API
  argument for sticking with the current proposal even though it is flawed
 and
 HTML5 is not yet final.  (It has also not been implemented by browsers for
 very long.)  Stated that way, it sounds like a weak argument for
 preserving
 the API as is, and we should just fix it to be better.

 My understanding is that removal is not a popular position.  However,
 given
 that more browsers are moving to be multi-process, I have to say that I'm
 a
 bit surprised there isn't more support for ditching the current
 localStorage
 API.


 You're preaching to the choir :) I'd recommend talking to apple and
 microsoft directly. I don't know what their plans are regarding all this.


Fair enough :-)







 Moreover, there are other examples which have been discussed on
 the
list.  There are some DOM operations that can result in a frame
receiving
a DOM event synchronously.  That can result in a nesting of
 storage
 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

  Moreover, there are other examples which have been discussed on
 the
list.  There are some DOM operations that can result in a frame
receiving
a DOM event synchronously.  That can result in a nesting of
 storage
locks,
which can force us to have to implicitly unlock the outermost
 lock to
avoid
deadlocks.  Again, the programmer will have very poor visibility
 into
when
these things can happen.
  
   So far I don't think it has been shown that these events need to
 be
   synchronous. They all appear to be asynchronous in gecko, and in
 the
   case of different-origin frames, I'm not even sure there's a way
 for
   pages to detect if the event was fired asynchronously or not.
  
   IE and WebKit dispatch some of them synchronously.  It's hard to
 say
   which
   is correct or if it causes any web compat isues.  I'm also not sure
 that
   we
   have covered all of the cases.
 
  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.




 ...snip...


   Not quite sure I follow your proposal. How would you for example
   increase the value of a property by one without risking race
   conditions? Or keep two values in different properties in sync?
 I.e.
   so that if you update one always update the other, so that they
 never
   have different values.
  
   / Jonas
  
  
   Easy.  Just like with database, the transaction is the storage
 lock.
Any
   storage
   operation performed on that transaction are done atomically.
  However,
   all
   storage
   operations are asynchronous.  You basically string together
 asynchronous
   storage
   operations by using the same transaction for each.
   We could add methods to get/set multiple items at once to simplify
 life
   for
   the coder.
 
  I think I still don't understand your proposal, could you give some
  code examples?
 
 
 
  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 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Fri, Oct 2, 2009 at 9:11 PM, Darin Fisher da...@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

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Fri, Oct 2, 2009 at 9:43 PM, Jonas Sicking jo...@sicking.cc wrote:

  Moreover, there are other examples which have been discussed on
 the
list.  There are some DOM operations that can result in a frame
receiving
a DOM event synchronously.  That can result in a nesting of
 storage
locks,
which can force us to have to implicitly unlock the outermost
 lock to
avoid
deadlocks.  Again, the programmer will have very poor
 visibility into
when
these things can happen.
  
   So far I don't think it has been shown that these events need to
 be
   synchronous. They all appear to be asynchronous in gecko, and in
 the
   case of different-origin frames, I'm not even sure there's a way
 for
   pages to detect if the event was fired asynchronously or not.
  
   IE and WebKit dispatch some of them synchronously.  It's hard to
 say
   which
   is correct or if it causes any web compat isues.  I'm also not
 sure that
   we
   have covered all of the cases.
 
  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.




 ...snip...


   Not quite sure I follow your proposal. How would you for example
   increase the value of a property by one without risking race
   conditions? Or keep two values in different properties in sync?
 I.e.
   so that if you update one always update the other, so that they
 never
   have different values.
  
   / Jonas
  
  
   Easy.  Just like with database, the transaction is the storage
 lock.
Any
   storage
   operation performed on that transaction are done atomically.
  However,
   all
   storage
   operations are asynchronous.  You basically string together
 asynchronous
   storage
   operations by using the same transaction for each.
   We could add methods to get/set multiple items at once to simplify
 life
   for
   the coder.
 
  I think I still don't understand your proposal, could you give some
  code examples?
 
 
 
  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 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Tue, Sep 29, 2009 at 12:19 AM, Darin Fisher da...@chromium.org wrote:
 On Thu, Sep 24, 2009 at 11:57 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Sep 24, 2009 at 9:04 PM, Darin Fisher da...@chromium.org wrote:
  On Thu, Sep 24, 2009 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher da...@chromium.org
  wrote:
   On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking jo...@sicking.cc
   wrote:
  
   On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org
   wrote:
On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc
wrote:
   
On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher
da...@chromium.org
wrote:

 ... snip ...


 multi-core is the future.  what's the opposite of fine-grained
 locking?
  it's not good ;-)
 the implicit locking mechanism as spec'd is super lame.
  implicitly
 unlocking under
 mysterious-to-the-developer circumstances!  how can that be a
 good
 thing?
 storage.setItem(y,
 function_involving_implicit_unlocking(storage.getItem(x)));
   
I totally agree on all points. The current API has big
imperfections.
However I haven't seen any workable counter proposals so far, and
I
honestly don't believe there are any as long as our goals are:
   
* Don't break existing users of the current implementations.
* Don't expose race conditions to the web.
* Don't rely on authors getting explicit locking mechanisms
right.
   
   
The current API exposes race conditions to the web.  The implicit
dropping of the storage lock is that.  In Chrome, we'll have to
drop
an existing lock whenever a new lock is acquired.  That can happen
due to a variety of really odd cases (usually related to nested
loops
or nested JS execution), which will be difficult for developers to
predict, especially if they are relying on third-party JS
libraries.
This issue seems to be discounted for reasons I do not understand.
  
   I don't believe we've heard about this before, so that would be the
   reason it hasn't been taken into account.
  
   So you're saying that chrome would be unable implement the current
   storage mutex as specified in spec? I.e. one that is only released
   at
   the explicit points that the spec defines? That seems like a huge
   problem.
  
   No, no... my point is that to the application developer, those
   explicit
   points will appear quite implicit and mysterious.  This is why I
   called
   out third-party JS libraries.  One day, a function that you are using
   might transition to scripting a plugin, which might cause a nested
   loop, which could then force the lock to be released.  As a
   programmer,
   the unlocking is not explicit or predictable.
 
  Ah, indeed, this is a problem. However the unfortunate fact remains
  that so far no other workable solution has been proposed.
 
  OK, so we agree that the current solution doesn't meet the goals you
  stated above :-(

 Well, it addresses them as long as users are aware of the risk, and
 properly document weather their various library functions will release
 the lock or not. However I agree that it's unlikely that they will do
 so correctly.

 I thought the point of not having lock APIs was that users shouldn't have
 to understand locks ;-)  The issue I've raised here is super subtle.  We
 have not succeeded in avoiding subtlety!

I think we're mostly in agreement. What I'm not sure about is what you
are proposing we do with localStorage? Remove it from the spec? Change
the API? Something else?

   Moreover, there are other examples which have been discussed on the
   list.  There are some DOM operations that can result in a frame
   receiving
   a DOM event synchronously.  That can result in a nesting of storage
   locks,
   which can force us to have to implicitly unlock the outermost lock to
   avoid
   deadlocks.  Again, the programmer will have very poor visibility into
   when
   these things can happen.
 
  So far I don't think it has been shown that these events need to be
  synchronous. They all appear to be asynchronous in gecko, and in the
  case of different-origin frames, I'm not even sure there's a way for
  pages to detect if the event was fired asynchronously or not.
 
  IE and WebKit dispatch some of them synchronously.  It's hard to say
  which
  is correct or if it causes any web compat isues.  I'm also not sure that
  we
  have covered all of the cases.

 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 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Thu, Sep 24, 2009 at 11:57 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Sep 24, 2009 at 9:04 PM, Darin Fisher da...@chromium.org wrote:
  On Thu, Sep 24, 2009 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher da...@chromium.org
 wrote:
   On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking jo...@sicking.cc
   wrote:
  
   On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org
   wrote:
On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc
wrote:
   
On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher 
 da...@chromium.org
wrote:


... snip ...


 multi-core is the future.  what's the opposite of fine-grained
 locking?
  it's not good ;-)
 the implicit locking mechanism as spec'd is super lame.
  implicitly
 unlocking under
 mysterious-to-the-developer circumstances!  how can that be a
 good
 thing?
 storage.setItem(y,
 function_involving_implicit_unlocking(storage.getItem(x)));
   
I totally agree on all points. The current API has big
imperfections.
However I haven't seen any workable counter proposals so far, and
 I
honestly don't believe there are any as long as our goals are:
   
* Don't break existing users of the current implementations.
* Don't expose race conditions to the web.
* Don't rely on authors getting explicit locking mechanisms right.
   
   
The current API exposes race conditions to the web.  The implicit
dropping of the storage lock is that.  In Chrome, we'll have to
 drop
an existing lock whenever a new lock is acquired.  That can happen
due to a variety of really odd cases (usually related to nested
 loops
or nested JS execution), which will be difficult for developers to
predict, especially if they are relying on third-party JS
 libraries.
This issue seems to be discounted for reasons I do not understand.
  
   I don't believe we've heard about this before, so that would be the
   reason it hasn't been taken into account.
  
   So you're saying that chrome would be unable implement the current
   storage mutex as specified in spec? I.e. one that is only released at
   the explicit points that the spec defines? That seems like a huge
   problem.
  
   No, no... my point is that to the application developer, those
   explicit
   points will appear quite implicit and mysterious.  This is why I
 called
   out third-party JS libraries.  One day, a function that you are using
   might transition to scripting a plugin, which might cause a nested
   loop, which could then force the lock to be released.  As a
 programmer,
   the unlocking is not explicit or predictable.
 
  Ah, indeed, this is a problem. However the unfortunate fact remains
  that so far no other workable solution has been proposed.
 
  OK, so we agree that the current solution doesn't meet the goals you
  stated above :-(

 Well, it addresses them as long as users are aware of the risk, and
 properly document weather their various library functions will release
 the lock or not. However I agree that it's unlikely that they will do
 so correctly.


I thought the point of not having lock APIs was that users shouldn't have
to understand locks ;-)  The issue I've raised here is super subtle.  We
have not succeeded in avoiding subtlety!




   Moreover, there are other examples which have been discussed on the
   list.  There are some DOM operations that can result in a frame
   receiving
   a DOM event synchronously.  That can result in a nesting of storage
   locks,
   which can force us to have to implicitly unlock the outermost lock to
   avoid
   deadlocks.  Again, the programmer will have very poor visibility into
   when
   these things can happen.
 
  So far I don't think it has been shown that these events need to be
  synchronous. They all appear to be asynchronous in gecko, and in the
  case of different-origin frames, I'm not even sure there's a way for
  pages to detect if the event was fired asynchronously or not.
 
  IE and WebKit dispatch some of them synchronously.  It's hard to say
 which
  is correct or if it causes any web compat isues.  I'm also not sure that
 we
  have covered all of the cases.

 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.




  Our approach to implementing implicit locking (if we must) will be to
 detect
  nested locking, and simply unlock the first held lock to basically
 prevent
  nested locking.  This way we don't have to know all of the cases where
 this
  can happen.

 So is 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org wrote:


 On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org wrote:
  On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org wrote:
   On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org
   wrote:
   What are the use cases for wanting to store data beyond strings (and
   what
   can be serialized into strings) in LocalStorage?  I can't think of
   any
   that
   outweigh the negatives:
   1)  From previous threads, I think it's fair to say that we can all
   agreed
   that LocalStorage is a regrettable API (mainly due to its
   synchronous
   nature).  If so, it seems that making it more powerful and thus more
   attractive to developers is just asking for trouble.  After all, the
   more
   people use it, the more lock contention there'll be, and the more
   browser UI
   jank users will be sure to experience.  This will also be worse
   because
   it'll be easier for developers to store large objects in
   LoaclStorage.
   2)  As far as I can tell, there's no where else in the spec where
   you
   have
   to serialize structured clone(able) data to disk.  Given that
   LocalStorage
   is supposed to throw an exception if any ImageData is contained and
   since
   File and FileData objects are legal, it seems as though making
   LocalStorage
   handle structured clone data has a fairly high cost to implementors.
    Not to
   mention that disallowing ImageData in only this one case is not
   intuitive.
   I think allowing structured clone(able) data in LocalStorage is a
   big
   mistake.  Enough so that, if SessionStorage and LocalStorage can't
   diverge
   on this issue, it'd be worth taking the power away from
   SessionStorage.
   J
  
   Speaking from experience, I have been using localStorage in my PhD
   thesis work w/o any real need for structured clones (I would have
   used
   Web Database but it isn't widely used yet and I was not sure if it
   was
   going to make the cut in the end). All it took to come close to
   simulating structured clones now was to develop my own compatibility
   wrapper for localStorage (http://realstorage.googlecode.com for those
   who care) and add setJSONObject() and getJSONObject() methods on the
   wrapper. Works w/o issue.
 
  Actually, this seems like a prime reason *to* add structured storage
  support. Obviously string data wasn't enough for you so you had to
  write extra code in order to work around that. If structured clones
  had been natively supported you both would have had to write less
  code, and the resulting algorithms would have been faster. Faster
  since the browser can serialize/parser to/from a binary internal
  format faster than to/from JSON through the JSON serializer/parser.
 
  Yes, but since LocalStorage is already widely deployed, authors are
  stuck
  with the the structured clone-less version of LocalStorage for a very
  long
  time.  So the only way an app can store anything that can't be JSONified
  is
  to break backwards compatibility.
 
 
 
  On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org
  wrote:
   What are the use cases for wanting to store data beyond strings (and
   what
   can be serialized into strings) in LocalStorage?  I can't think of
   any
   that
   outweigh the negatives:
   1)  From previous threads, I think it's fair to say that we can all
   agreed
   that LocalStorage is a regrettable API (mainly due to its synchronous
   nature).  If so, it seems that making it more powerful and thus more
   attractive to developers is just asking for trouble.  After all, the
   more
   people use it, the more lock contention there'll be, and the more
   browser UI
   jank users will be sure to experience.  This will also be worse
   because
   it'll be easier for developers to store large objects in
   LoaclStorage.
   2)  As far as I can tell, there's no where else in the spec where you
   have
   to serialize structured clone(able) data to disk.  Given that
   LocalStorage
   is supposed to throw an exception if any ImageData is contained and
   since
   File and FileData objects are legal, it seems as though making
   LocalStorage
   handle structured clone data has a fairly high cost to implementors.
    Not to
   mention that disallowing ImageData in only this one case is not
   intuitive.
   I think allowing structured clone(able) data in LocalStorage is a big
   mistake.  Enough so that, if SessionStorage and LocalStorage can't
   diverge
   on this issue, it'd be worth taking the power away from
   SessionStorage.
 
  Despite localStorage unfortunate locking contention problem, it's
  become quite a popular API. It's also very successful in terms of
  browser deployment since 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org wrote:
 
 
  On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org
 wrote:
   On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc
 wrote:
  
   On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org
 wrote:
On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org
wrote:
What are the use cases for wanting to store data beyond strings
 (and
what
can be serialized into strings) in LocalStorage?  I can't think of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can
 all
agreed
that LocalStorage is a regrettable API (mainly due to its
synchronous
nature).  If so, it seems that making it more powerful and thus
 more
attractive to developers is just asking for trouble.  After all,
 the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained
 and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
 implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data in LocalStorage is a
big
mistake.  Enough so that, if SessionStorage and LocalStorage can't
diverge
on this issue, it'd be worth taking the power away from
SessionStorage.
J
   
Speaking from experience, I have been using localStorage in my PhD
thesis work w/o any real need for structured clones (I would have
used
Web Database but it isn't widely used yet and I was not sure if it
was
going to make the cut in the end). All it took to come close to
simulating structured clones now was to develop my own
 compatibility
wrapper for localStorage (http://realstorage.googlecode.com for
 those
who care) and add setJSONObject() and getJSONObject() methods on
 the
wrapper. Works w/o issue.
  
   Actually, this seems like a prime reason *to* add structured storage
   support. Obviously string data wasn't enough for you so you had to
   write extra code in order to work around that. If structured clones
   had been natively supported you both would have had to write less
   code, and the resulting algorithms would have been faster. Faster
   since the browser can serialize/parser to/from a binary internal
   format faster than to/from JSON through the JSON serializer/parser.
  
   Yes, but since LocalStorage is already widely deployed, authors are
   stuck
   with the the structured clone-less version of LocalStorage for a very
   long
   time.  So the only way an app can store anything that can't be
 JSONified
   is
   to break backwards compatibility.
  
  
  
   On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking jo...@sicking.cc
  wrote:
  
   On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org
   wrote:
What are the use cases for wanting to store data beyond strings
 (and
what
can be serialized into strings) in LocalStorage?  I can't think of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can all
agreed
that LocalStorage is a regrettable API (mainly due to its
 synchronous
nature).  If so, it seems that making it more powerful and thus
 more
attractive to developers is just asking for trouble.  After all,
 the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
 you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
 implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data in LocalStorage is a
 big
mistake.  Enough so that, if SessionStorage and LocalStorage can't
diverge
on this issue, it'd be worth 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org wrote:

 On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org
 wrote:
 
 
  On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc
 wrote:
 
  On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org
 wrote:
   On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc
 wrote:
  
   On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org
 wrote:
On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org
wrote:
What are the use cases for wanting to store data beyond strings
 (and
what
can be serialized into strings) in LocalStorage?  I can't think
 of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can
 all
agreed
that LocalStorage is a regrettable API (mainly due to its
synchronous
nature).  If so, it seems that making it more powerful and thus
 more
attractive to developers is just asking for trouble.  After all,
 the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained
 and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
 implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data in LocalStorage is a
big
mistake.  Enough so that, if SessionStorage and LocalStorage
 can't
diverge
on this issue, it'd be worth taking the power away from
SessionStorage.
J
   
Speaking from experience, I have been using localStorage in my PhD
thesis work w/o any real need for structured clones (I would have
used
Web Database but it isn't widely used yet and I was not sure if it
was
going to make the cut in the end). All it took to come close to
simulating structured clones now was to develop my own
 compatibility
wrapper for localStorage (http://realstorage.googlecode.com for
 those
who care) and add setJSONObject() and getJSONObject() methods on
 the
wrapper. Works w/o issue.
  
   Actually, this seems like a prime reason *to* add structured storage
   support. Obviously string data wasn't enough for you so you had to
   write extra code in order to work around that. If structured clones
   had been natively supported you both would have had to write less
   code, and the resulting algorithms would have been faster. Faster
   since the browser can serialize/parser to/from a binary internal
   format faster than to/from JSON through the JSON serializer/parser.
  
   Yes, but since LocalStorage is already widely deployed, authors are
   stuck
   with the the structured clone-less version of LocalStorage for a very
   long
   time.  So the only way an app can store anything that can't be
 JSONified
   is
   to break backwards compatibility.
  
  
  
   On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking jo...@sicking.cc
  wrote:
  
   On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org
   wrote:
What are the use cases for wanting to store data beyond strings
 (and
what
can be serialized into strings) in LocalStorage?  I can't think of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can
 all
agreed
that LocalStorage is a regrettable API (mainly due to its
 synchronous
nature).  If so, it seems that making it more powerful and thus
 more
attractive to developers is just asking for trouble.  After all,
 the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
 you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained
 and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
 implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data in LocalStorage is a
 big
mistake.  Enough so that, if 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jeremy Orlow]

On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org wrote:
 
 
  On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org
 wrote:
   On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc
 wrote:
  
   On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org
 wrote:
On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org
wrote:
What are the use cases for wanting to store data beyond strings
 (and
what
can be serialized into strings) in LocalStorage?  I can't think of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can
 all
agreed
that LocalStorage is a regrettable API (mainly due to its
synchronous
nature).  If so, it seems that making it more powerful and thus
 more
attractive to developers is just asking for trouble.  After all,
 the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained
 and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
 implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data in LocalStorage is a
big
mistake.  Enough so that, if SessionStorage and LocalStorage can't
diverge
on this issue, it'd be worth taking the power away from
SessionStorage.
J
   
Speaking from experience, I have been using localStorage in my PhD
thesis work w/o any real need for structured clones (I would have
used
Web Database but it isn't widely used yet and I was not sure if it
was
going to make the cut in the end). All it took to come close to
simulating structured clones now was to develop my own
 compatibility
wrapper for localStorage (http://realstorage.googlecode.com for
 those
who care) and add setJSONObject() and getJSONObject() methods on
 the
wrapper. Works w/o issue.
  
   Actually, this seems like a prime reason *to* add structured storage
   support. Obviously string data wasn't enough for you so you had to
   write extra code in order to work around that. If structured clones
   had been natively supported you both would have had to write less
   code, and the resulting algorithms would have been faster. Faster
   since the browser can serialize/parser to/from a binary internal
   format faster than to/from JSON through the JSON serializer/parser.
  
   Yes, but since LocalStorage is already widely deployed, authors are
   stuck
   with the the structured clone-less version of LocalStorage for a very
   long
   time.  So the only way an app can store anything that can't be
 JSONified
   is
   to break backwards compatibility.
  
  
  
   On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking jo...@sicking.cc
  wrote:
  
   On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org
   wrote:
What are the use cases for wanting to store data beyond strings
 (and
what
can be serialized into strings) in LocalStorage?  I can't think of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can all
agreed
that LocalStorage is a regrettable API (mainly due to its
 synchronous
nature).  If so, it seems that making it more powerful and thus
 more
attractive to developers is just asking for trouble.  After all,
 the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
 you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
 implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data in LocalStorage is a
 big
mistake.  Enough so that, if SessionStorage and LocalStorage can't
diverge
on this issue, it'd be worth 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org wrote:
 On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org wrote:
 
 
  On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org
  wrote:
   On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc
   wrote:
  
   On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org
   wrote:
On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org
wrote:
What are the use cases for wanting to store data beyond strings
(and
what
can be serialized into strings) in LocalStorage?  I can't think
of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can
all
agreed
that LocalStorage is a regrettable API (mainly due to its
synchronous
nature).  If so, it seems that making it more powerful and thus
more
attractive to developers is just asking for trouble.  After all,
the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained
and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data in LocalStorage is a
big
mistake.  Enough so that, if SessionStorage and LocalStorage
can't
diverge
on this issue, it'd be worth taking the power away from
SessionStorage.
J
   
Speaking from experience, I have been using localStorage in my PhD
thesis work w/o any real need for structured clones (I would have
used
Web Database but it isn't widely used yet and I was not sure if it
was
going to make the cut in the end). All it took to come close to
simulating structured clones now was to develop my own
compatibility
wrapper for localStorage (http://realstorage.googlecode.com for
those
who care) and add setJSONObject() and getJSONObject() methods on
the
wrapper. Works w/o issue.
  
   Actually, this seems like a prime reason *to* add structured storage
   support. Obviously string data wasn't enough for you so you had to
   write extra code in order to work around that. If structured clones
   had been natively supported you both would have had to write less
   code, and the resulting algorithms would have been faster. Faster
   since the browser can serialize/parser to/from a binary internal
   format faster than to/from JSON through the JSON serializer/parser.
  
   Yes, but since LocalStorage is already widely deployed, authors are
   stuck
   with the the structured clone-less version of LocalStorage for a very
   long
   time.  So the only way an app can store anything that can't be
   JSONified
   is
   to break backwards compatibility.
  
  
  
   On Wed, Sep 23, 2009 at 3:11 PM, Jonas
   Sicking jo...@sicking.cc wrote:
  
   On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org
   wrote:
What are the use cases for wanting to store data beyond strings
(and
what
can be serialized into strings) in LocalStorage?  I can't think of
any
that
outweigh the negatives:
1)  From previous threads, I think it's fair to say that we can
all
agreed
that LocalStorage is a regrettable API (mainly due to its
synchronous
nature).  If so, it seems that making it more powerful and thus
more
attractive to developers is just asking for trouble.  After all,
the
more
people use it, the more lock contention there'll be, and the more
browser UI
jank users will be sure to experience.  This will also be worse
because
it'll be easier for developers to store large objects in
LoaclStorage.
2)  As far as I can tell, there's no where else in the spec where
you
have
to serialize structured clone(able) data to disk.  Given that
LocalStorage
is supposed to throw an exception if any ImageData is contained
and
since
File and FileData objects are legal, it seems as though making
LocalStorage
handle structured clone data has a fairly high cost to
implementors.
 Not to
mention that disallowing ImageData in only this one case is not
intuitive.
I think allowing structured clone(able) data 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org wrote:
  On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc
 wrote:
 
  On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org
 wrote:
  
  
   On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc
 wrote:
  
   On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org
   wrote:
On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc
wrote:
   
On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org
wrote:
 On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow 
 jor...@chromium.org
 wrote:
 What are the use cases for wanting to store data beyond strings
 (and
 what
 can be serialized into strings) in LocalStorage?  I can't think
 of
 any
 that
 outweigh the negatives:
 1)  From previous threads, I think it's fair to say that we can
 all
 agreed
 that LocalStorage is a regrettable API (mainly due to its
 synchronous
 nature).  If so, it seems that making it more powerful and thus
 more
 attractive to developers is just asking for trouble.  After
 all,
 the
 more
 people use it, the more lock contention there'll be, and the
 more
 browser UI
 jank users will be sure to experience.  This will also be worse
 because
 it'll be easier for developers to store large objects in
 LoaclStorage.
 2)  As far as I can tell, there's no where else in the spec
 where
 you
 have
 to serialize structured clone(able) data to disk.  Given that
 LocalStorage
 is supposed to throw an exception if any ImageData is contained
 and
 since
 File and FileData objects are legal, it seems as though making
 LocalStorage
 handle structured clone data has a fairly high cost to
 implementors.
  Not to
 mention that disallowing ImageData in only this one case is not
 intuitive.
 I think allowing structured clone(able) data in LocalStorage is
 a
 big
 mistake.  Enough so that, if SessionStorage and LocalStorage
 can't
 diverge
 on this issue, it'd be worth taking the power away from
 SessionStorage.
 J

 Speaking from experience, I have been using localStorage in my
 PhD
 thesis work w/o any real need for structured clones (I would
 have
 used
 Web Database but it isn't widely used yet and I was not sure if
 it
 was
 going to make the cut in the end). All it took to come close to
 simulating structured clones now was to develop my own
 compatibility
 wrapper for localStorage (http://realstorage.googlecode.com for
 those
 who care) and add setJSONObject() and getJSONObject() methods on
 the
 wrapper. Works w/o issue.
   
Actually, this seems like a prime reason *to* add structured
 storage
support. Obviously string data wasn't enough for you so you had to
write extra code in order to work around that. If structured
 clones
had been natively supported you both would have had to write less
code, and the resulting algorithms would have been faster. Faster
since the browser can serialize/parser to/from a binary internal
format faster than to/from JSON through the JSON
 serializer/parser.
   
Yes, but since LocalStorage is already widely deployed, authors are
stuck
with the the structured clone-less version of LocalStorage for a
 very
long
time.  So the only way an app can store anything that can't be
JSONified
is
to break backwards compatibility.
   
   
   
On Wed, Sep 23, 2009 at 3:11 PM, Jonas
Sicking jo...@sicking.cc wrote:
   
On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow 
 jor...@chromium.org
wrote:
 What are the use cases for wanting to store data beyond strings
 (and
 what
 can be serialized into strings) in LocalStorage?  I can't think
 of
 any
 that
 outweigh the negatives:
 1)  From previous threads, I think it's fair to say that we can
 all
 agreed
 that LocalStorage is a regrettable API (mainly due to its
 synchronous
 nature).  If so, it seems that making it more powerful and thus
 more
 attractive to developers is just asking for trouble.  After all,
 the
 more
 people use it, the more lock contention there'll be, and the
 more
 browser UI
 jank users will be sure to experience.  This will also be worse
 because
 it'll be easier for developers to store large objects in
 LoaclStorage.
 2)  As far as I can tell, there's no where else in the spec
 where
 you
 have
 to serialize structured clone(able) data to disk.  Given that
 LocalStorage
 is supposed to throw an exception if any ImageData is contained
 and
 since
 File and FileData objects are legal, it seems as though making
 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Brett Cannon]

On Thu, Sep 24, 2009 at 01:45, Jeremy Orlow jor...@chromium.org wrote:
[SNIP]
 These are all good suggestions, but I'm not sure even that API would be
 powerful enough for developers.
 thought exercise
 For example, how would you implement an offline webmail app?  Well, my first
 thought is to make each email a key/value.  But we can't iterate over ranges
 of keys, so that won't work.  Maybe instead we can make each key a folder
 for our mail?  We could store all the mails in an array.  But that could be
 a huge amount of data in each key--on the order of hundreds of megabytes for
 some users.  So, to optimize, I guess we could store the emails in their own
 keys and then just store large arrays of mail keys in each folder key.  This
 would also solve the problem of gmail-like labels (i.e. a many to one
 relationship between folders/labels to emails).  Oh yeah, and we'd need to
 have one key that's a list of all the folders.
 Great.  But now we want to allow offline searching of our emails.  Crap.
  Well we can efficiently search arrays with a binary search.  But that takes
 a while to update.  Well, we can implement a balanced tree for each index
 and then store it in keys.  And have one key that has a list of all our
 index keys.  This seems reasonably efficient--as long as the trees don't get
 too big.  Even if the implementation is pretty slick, once they get to a
 certain size, just loading one key into memory could take a while.
  Especially since the entire time we're updating/reading/whatever our keys,
 we're either starving other tabs from accessing the data or blocking their
 event loop.
 /thought exercise 
 So yes: I do think that you can create at least a simple web mail client.
  And, as long as the JavaScript engine is fast enough to handle large,
 complex data structures (without running out of memory!), I suppose you
 probably could build just about anything on top of it.
 But realistically, it seems that (at a minimum) we need to add a way to
 iterate over ranges of keys and something with multiple storage areas (as
 you suggested).  Honestly, I can't think of anything else that seems super
 important right now.  (Though I know the gmail guys would say they need full
 text search.  :-)
 If it'd be helpful, I could maybe ask some developers here at Google how
 they'd like to use LocalStorage to get some more concrete use cases.

To give a data point I can tell you all about my PhD thesis work that
involves localStorage. Basically I am looking at how to automate the
persistence of JavaScript data objects (i.e. stuff JSON supports) both
locally for performance/offline reasons, and to the cloud for
synchronization/backup reasons. For the browser side I am using
localStorage to store the objects.

I have ended up using localStorage by using keys that represent
pointers for objects with the values being the JSON string for that
object. This essentially lets me treat localStorage as an object
store. With some other JavaScript trickery I am able to load only the
objects I need and avoid loading the rest of the object graph,
avoiding performance costs when trying to stringify a large object
graph at once.

Talking directly to the structured clones direction, I have to say
that I personally would rather have it revert back to strings. With my
persistence hat on I would say it would be a slight convenience, but
with my localStorage-browser-compatibility-library hat on I would say
that it is going to be a huge pain in the rear to add support for the
browsers already out there for minor benefit.

So if I can build an automated data object persistence object on top
of localStorage as it is implemented in the browsers today (sans
incompatibilities) then I think your assessment, Jeremy, is true that
localStorage can be used as the storage basis for things, and w/o
structured clones to boot.

-Brett

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher da...@chromium.org wrote:
 On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org wrote:
  On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc
  wrote:
 
  On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org
  wrote:
  
  
   On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc
   wrote:
  
   On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org
   wrote:
On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc
wrote:
   
On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org
wrote:
 On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow
 jor...@chromium.org
 wrote:
 What are the use cases for wanting to store data beyond
 strings
 (and
 what
 can be serialized into strings) in LocalStorage?  I can't
 think
 of
 any
 that
 outweigh the negatives:
 1)  From previous threads, I think it's fair to say that we
 can
 all
 agreed
 that LocalStorage is a regrettable API (mainly due to its
 synchronous
 nature).  If so, it seems that making it more powerful and
 thus
 more
 attractive to developers is just asking for trouble.  After
 all,
 the
 more
 people use it, the more lock contention there'll be, and the
 more
 browser UI
 jank users will be sure to experience.  This will also be
 worse
 because
 it'll be easier for developers to store large objects in
 LoaclStorage.
 2)  As far as I can tell, there's no where else in the spec
 where
 you
 have
 to serialize structured clone(able) data to disk.  Given that
 LocalStorage
 is supposed to throw an exception if any ImageData is
 contained
 and
 since
 File and FileData objects are legal, it seems as though making
 LocalStorage
 handle structured clone data has a fairly high cost to
 implementors.
  Not to
 mention that disallowing ImageData in only this one case is
 not
 intuitive.
 I think allowing structured clone(able) data in LocalStorage
 is a
 big
 mistake.  Enough so that, if SessionStorage and LocalStorage
 can't
 diverge
 on this issue, it'd be worth taking the power away from
 SessionStorage.
 J

 Speaking from experience, I have been using localStorage in my
 PhD
 thesis work w/o any real need for structured clones (I would
 have
 used
 Web Database but it isn't widely used yet and I was not sure if
 it
 was
 going to make the cut in the end). All it took to come close to
 simulating structured clones now was to develop my own
 compatibility
 wrapper for localStorage (http://realstorage.googlecode.com for
 those
 who care) and add setJSONObject() and getJSONObject() methods
 on
 the
 wrapper. Works w/o issue.
   
Actually, this seems like a prime reason *to* add structured
storage
support. Obviously string data wasn't enough for you so you had
to
write extra code in order to work around that. If structured
clones
had been natively supported you both would have had to write less
code, and the resulting algorithms would have been faster. Faster
since the browser can serialize/parser to/from a binary internal
format faster than to/from JSON through the JSON
serializer/parser.
   
Yes, but since LocalStorage is already widely deployed, authors
are
stuck
with the the structured clone-less version of LocalStorage for a
very
long
time.  So the only way an app can store anything that can't be
JSONified
is
to break backwards compatibility.
   
   
   
On Wed, Sep 23, 2009 at 3:11 PM, Jonas
Sicking jo...@sicking.cc wrote:
   
On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow
jor...@chromium.org
wrote:
 What are the use cases for wanting to store data beyond strings
 (and
 what
 can be serialized into strings) in LocalStorage?  I can't think
 of
 any
 that
 outweigh the negatives:
 1)  From previous threads, I think it's fair to say that we can
 all
 agreed
 that LocalStorage is a regrettable API (mainly due to its
 synchronous
 nature).  If so, it seems that making it more powerful and thus
 more
 attractive to developers is just asking for trouble.  After
 all,
 the
 more
 people use it, the more lock contention there'll be, and the
 more
 browser UI
 jank users will be sure to experience.  This will also be worse
 because
 it'll be easier for developers to store large objects in
 LoaclStorage.
 2)  As far as I can tell, there's no where else in the spec
 where
 you
 have
 to serialize structured clone(able) data to disk.  Given 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Maciej Stachowiak]

On Sep 23, 2009, at 3:29 PM, Jeremy Orlow wrote:



In addition, this argument assumes that Microsoft (and other UAs)  
will implement the structured clone version of LocalStorage.  Has  
anyone (or can anyone) from Microsoft comment on this?


Microsoft doesn't always comment on such issues, but they are more  
likely to answer on public-h...@w3.org, where they have been fairly  
actively participating lately, than here, where they do not subscribe  
to or read the list as a matter of policy.


Regards,
Maciej

Re: [whatwg] Structured clone algorithm on LocalStorage

[Robert O'Callahan]

On Fri, Sep 25, 2009 at 5:52 AM, Darin Fisher da...@chromium.org wrote:

 No, no... my point is that to the application developer, those explicit
 points will appear quite implicit and mysterious.  This is why I called
 out third-party JS libraries.  One day, a function that you are using
 might transition to scripting a plugin, which might cause a nested
 loop, which could then force the lock to be released.  As a programmer,
 the unlocking is not explicit or predictable.


The unlocking around plugin calls is a problem, but it seems to me that any
given library function is much more likely start with a plugin-based
implementation and eventually switch to a non-plugin-based implementation
than the other way around.

Beyond plugins, I hope and expect that library functions don't suddenly add
calls to alert(), showModalDialog() or synchronous XHR.

Rob
-- 
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]

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Thu, Sep 24, 2009 at 9:28 PM, Robert O'Callahan rob...@ocallahan.orgwrote:

 On Fri, Sep 25, 2009 at 5:52 AM, Darin Fisher da...@chromium.org wrote:

 No, no... my point is that to the application developer, those explicit
 points will appear quite implicit and mysterious.  This is why I called
 out third-party JS libraries.  One day, a function that you are using
 might transition to scripting a plugin, which might cause a nested
 loop, which could then force the lock to be released.  As a programmer,
 the unlocking is not explicit or predictable.


 The unlocking around plugin calls is a problem, but it seems to me that any
 given library function is much more likely start with a plugin-based
 implementation and eventually switch to a non-plugin-based implementation
 than the other way around.


Suppose a library decides to add sound effects one day.  They'd probably use
Flash.



 Beyond plugins, I hope and expect that library functions don't suddenly add
 calls to alert(), showModalDialog() or synchronous XHR.

 Rob



Anyways, I will the first to admit that my argument is steeped in the
hypothetical, but when it comes to thread synchronization, it is important
to consider such unlikely cases.  I would greatly prefer a watertight
solution instead of just relying on probabilities.

-Darin

Re: [whatwg] Structured clone algorithm on LocalStorage

[João Eiras]

and the more browser UI jank users will be sure to experience.


If I may, as a side note, locking the UI is a user agent specific issue.  
No specification requires user agents to lock their UIs while scripts  
execute.
Opera has achieved this long time ago, by properly dividing ecmascript  
execution with all the other tasks, and the new browsers with  
multi-process architecture also do not suffer from this problem.

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jeremy Orlow]

On Wed, Sep 23, 2009 at 1:46 PM, João Eiras jo...@opera.com wrote:


  and the more browser UI jank users will be sure to experience.


 If I may, as a side note, locking the UI is a user agent specific issue. No
 specification requires user agents to lock their UIs while scripts execute.
 Opera has achieved this long time ago, by properly dividing ecmascript
 execution with all the other tasks, and the new browsers with multi-process
 architecture also do not suffer from this problem.


You're right; I misspoke.

It is true, however, that any web pages in the same event loop will be
janky.  And multi-process browsers can't always put every tab in its own
process, so this can even affect multi-process browsers.

Re: [whatwg] Structured clone algorithm on LocalStorage

[Brett Cannon]

On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org wrote:
 What are the use cases for wanting to store data beyond strings (and what
 can be serialized into strings) in LocalStorage?  I can't think of any that
 outweigh the negatives:
 1)  From previous threads, I think it's fair to say that we can all agreed
 that LocalStorage is a regrettable API (mainly due to its synchronous
 nature).  If so, it seems that making it more powerful and thus more
 attractive to developers is just asking for trouble.  After all, the more
 people use it, the more lock contention there'll be, and the more browser UI
 jank users will be sure to experience.  This will also be worse because
 it'll be easier for developers to store large objects in LoaclStorage.
 2)  As far as I can tell, there's no where else in the spec where you have
 to serialize structured clone(able) data to disk.  Given that LocalStorage
 is supposed to throw an exception if any ImageData is contained and since
 File and FileData objects are legal, it seems as though making LocalStorage
 handle structured clone data has a fairly high cost to implementors.  Not to
 mention that disallowing ImageData in only this one case is not intuitive.
 I think allowing structured clone(able) data in LocalStorage is a big
 mistake.  Enough so that, if SessionStorage and LocalStorage can't diverge
 on this issue, it'd be worth taking the power away from SessionStorage.
 J

Speaking from experience, I have been using localStorage in my PhD
thesis work w/o any real need for structured clones (I would have used
Web Database but it isn't widely used yet and I was not sure if it was
going to make the cut in the end). All it took to come close to
simulating structured clones now was to develop my own compatibility
wrapper for localStorage (http://realstorage.googlecode.com for those
who care) and add setJSONObject() and getJSONObject() methods on the
wrapper. Works w/o issue.

Actually, there is a third drawback to the structured clones, which is
creating a backwards-compatible layer for existing browsers to
simulate structured clones will probably be hard. Since JSON does not
cover the new object types being introduced in HTML5 you will most
likely have to stringify all the file types some how, prefix a type to
the JSON string, and then on getItem() parse the string.

But the constructor for all the types covered by the structured clone
algorithm will not let you create a perfect copy. Take RegExp; the
structured clone spec says you get to skip lastIndex. OK, but what
about constructing a RegExp object with the proper input, lastMatch,
lastParen, etc.? Would a wrapper have to re-execute the search on the
RegExp to fast-forward to the proper state of the stored object? That
sounds painful.

If you all are regretting localStorage already even though it's
deployed using strings on most browsers (I think Opera doesn't have
it?), I would agree with Jeremy that perhaps this part of the spec
should just be considered dead and not fiddled with to try to
improve it.

-Brett

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote:
 What are the use cases for wanting to store data beyond strings (and what
 can be serialized into strings) in LocalStorage?  I can't think of any that
 outweigh the negatives:
 1)  From previous threads, I think it's fair to say that we can all agreed
 that LocalStorage is a regrettable API (mainly due to its synchronous
 nature).  If so, it seems that making it more powerful and thus more
 attractive to developers is just asking for trouble.  After all, the more
 people use it, the more lock contention there'll be, and the more browser UI
 jank users will be sure to experience.  This will also be worse because
 it'll be easier for developers to store large objects in LoaclStorage.
 2)  As far as I can tell, there's no where else in the spec where you have
 to serialize structured clone(able) data to disk.  Given that LocalStorage
 is supposed to throw an exception if any ImageData is contained and since
 File and FileData objects are legal, it seems as though making LocalStorage
 handle structured clone data has a fairly high cost to implementors.  Not to
 mention that disallowing ImageData in only this one case is not intuitive.
 I think allowing structured clone(able) data in LocalStorage is a big
 mistake.  Enough so that, if SessionStorage and LocalStorage can't diverge
 on this issue, it'd be worth taking the power away from SessionStorage.

Despite localStorage unfortunate locking contention problem, it's
become quite a popular API. It's also very successful in terms of
browser deployment since it's available in at least latest versions of
IE, Safari, Firefox, and Chrome. Don't know about support in Opera?

Browser UI jank isn't a problem as far as I can tell though. In
multi-process browsers the browser UI generally runs in a process
separate from the web page and so is not affected by the lock. In
single process browsers no lock is needed as there aren't multiple
processes that can access the localStorage at the same time.

Any time you store data into localStorage it seems useful to store
structured data. Say for example an webmail implementation storing
emails in each localStorage entry, in this case it would be possible
to store email body, from, to, date, flags, etc in a structured way.

Another reason is the ability to store file objects. This is something
that's important in order to be able to implement for example offline
email with attachments.

Note that while storing File objects is supported, you don't actually
need to store the data in it synchronously. Instead you can
asynchronously stream the filedata anyplace, and simply store a
pointer in the localStorage to that location.

/ Jonas

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org wrote:
 On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org wrote:
 What are the use cases for wanting to store data beyond strings (and what
 can be serialized into strings) in LocalStorage?  I can't think of any that
 outweigh the negatives:
 1)  From previous threads, I think it's fair to say that we can all agreed
 that LocalStorage is a regrettable API (mainly due to its synchronous
 nature).  If so, it seems that making it more powerful and thus more
 attractive to developers is just asking for trouble.  After all, the more
 people use it, the more lock contention there'll be, and the more browser UI
 jank users will be sure to experience.  This will also be worse because
 it'll be easier for developers to store large objects in LoaclStorage.
 2)  As far as I can tell, there's no where else in the spec where you have
 to serialize structured clone(able) data to disk.  Given that LocalStorage
 is supposed to throw an exception if any ImageData is contained and since
 File and FileData objects are legal, it seems as though making LocalStorage
 handle structured clone data has a fairly high cost to implementors.  Not to
 mention that disallowing ImageData in only this one case is not intuitive.
 I think allowing structured clone(able) data in LocalStorage is a big
 mistake.  Enough so that, if SessionStorage and LocalStorage can't diverge
 on this issue, it'd be worth taking the power away from SessionStorage.
 J

 Speaking from experience, I have been using localStorage in my PhD
 thesis work w/o any real need for structured clones (I would have used
 Web Database but it isn't widely used yet and I was not sure if it was
 going to make the cut in the end). All it took to come close to
 simulating structured clones now was to develop my own compatibility
 wrapper for localStorage (http://realstorage.googlecode.com for those
 who care) and add setJSONObject() and getJSONObject() methods on the
 wrapper. Works w/o issue.

Actually, this seems like a prime reason *to* add structured storage
support. Obviously string data wasn't enough for you so you had to
write extra code in order to work around that. If structured clones
had been natively supported you both would have had to write less
code, and the resulting algorithms would have been faster. Faster
since the browser can serialize/parser to/from a binary internal
format faster than to/from JSON through the JSON serializer/parser.

/ Jonas

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jeremy Orlow]

On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org wrote:
  On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org wrote:
  What are the use cases for wanting to store data beyond strings (and
 what
  can be serialized into strings) in LocalStorage?  I can't think of any
 that
  outweigh the negatives:
  1)  From previous threads, I think it's fair to say that we can all
 agreed
  that LocalStorage is a regrettable API (mainly due to its synchronous
  nature).  If so, it seems that making it more powerful and thus more
  attractive to developers is just asking for trouble.  After all, the
 more
  people use it, the more lock contention there'll be, and the more
 browser UI
  jank users will be sure to experience.  This will also be worse because
  it'll be easier for developers to store large objects in LoaclStorage.
  2)  As far as I can tell, there's no where else in the spec where you
 have
  to serialize structured clone(able) data to disk.  Given that
 LocalStorage
  is supposed to throw an exception if any ImageData is contained and
 since
  File and FileData objects are legal, it seems as though making
 LocalStorage
  handle structured clone data has a fairly high cost to implementors.
  Not to
  mention that disallowing ImageData in only this one case is not
 intuitive.
  I think allowing structured clone(able) data in LocalStorage is a big
  mistake.  Enough so that, if SessionStorage and LocalStorage can't
 diverge
  on this issue, it'd be worth taking the power away from SessionStorage.
  J
 
  Speaking from experience, I have been using localStorage in my PhD
  thesis work w/o any real need for structured clones (I would have used
  Web Database but it isn't widely used yet and I was not sure if it was
  going to make the cut in the end). All it took to come close to
  simulating structured clones now was to develop my own compatibility
  wrapper for localStorage (http://realstorage.googlecode.com for those
  who care) and add setJSONObject() and getJSONObject() methods on the
  wrapper. Works w/o issue.

 Actually, this seems like a prime reason *to* add structured storage
 support. Obviously string data wasn't enough for you so you had to
 write extra code in order to work around that. If structured clones
 had been natively supported you both would have had to write less
 code, and the resulting algorithms would have been faster. Faster
 since the browser can serialize/parser to/from a binary internal
 format faster than to/from JSON through the JSON serializer/parser.


Yes, but since LocalStorage is already widely deployed, authors are stuck
with the the structured clone-less version of LocalStorage for a very long
time.  So the only way an app can store anything that can't be JSONified is
to break backwards compatibility.




On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote:
  What are the use cases for wanting to store data beyond strings (and what
  can be serialized into strings) in LocalStorage?  I can't think of any
 that
  outweigh the negatives:
  1)  From previous threads, I think it's fair to say that we can all
 agreed
  that LocalStorage is a regrettable API (mainly due to its synchronous
  nature).  If so, it seems that making it more powerful and thus more
  attractive to developers is just asking for trouble.  After all, the more
  people use it, the more lock contention there'll be, and the more browser
 UI
  jank users will be sure to experience.  This will also be worse because
  it'll be easier for developers to store large objects in LoaclStorage.
  2)  As far as I can tell, there's no where else in the spec where you
 have
  to serialize structured clone(able) data to disk.  Given that
 LocalStorage
  is supposed to throw an exception if any ImageData is contained and since
  File and FileData objects are legal, it seems as though making
 LocalStorage
  handle structured clone data has a fairly high cost to implementors.  Not
 to
  mention that disallowing ImageData in only this one case is not
 intuitive.
  I think allowing structured clone(able) data in LocalStorage is a big
  mistake.  Enough so that, if SessionStorage and LocalStorage can't
 diverge
  on this issue, it'd be worth taking the power away from SessionStorage.

 Despite localStorage unfortunate locking contention problem, it's
 become quite a popular API. It's also very successful in terms of
 browser deployment since it's available in at least latest versions of
 IE, Safari, Firefox, and Chrome. Don't know about support in Opera?


The more popular it becomes, the more it's going to hurt UA developers, web
developers, and users.  I don't see why this is an argument for making it
more powerful.

In addition, this argument assumes that Microsoft (and other UAs) will
implement the structured clone version of 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Jonas Sicking]

On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org wrote:
 On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org wrote:
  On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org wrote:
  What are the use cases for wanting to store data beyond strings (and
  what
  can be serialized into strings) in LocalStorage?  I can't think of any
  that
  outweigh the negatives:
  1)  From previous threads, I think it's fair to say that we can all
  agreed
  that LocalStorage is a regrettable API (mainly due to its synchronous
  nature).  If so, it seems that making it more powerful and thus more
  attractive to developers is just asking for trouble.  After all, the
  more
  people use it, the more lock contention there'll be, and the more
  browser UI
  jank users will be sure to experience.  This will also be worse because
  it'll be easier for developers to store large objects in LoaclStorage.
  2)  As far as I can tell, there's no where else in the spec where you
  have
  to serialize structured clone(able) data to disk.  Given that
  LocalStorage
  is supposed to throw an exception if any ImageData is contained and
  since
  File and FileData objects are legal, it seems as though making
  LocalStorage
  handle structured clone data has a fairly high cost to implementors.
   Not to
  mention that disallowing ImageData in only this one case is not
  intuitive.
  I think allowing structured clone(able) data in LocalStorage is a big
  mistake.  Enough so that, if SessionStorage and LocalStorage can't
  diverge
  on this issue, it'd be worth taking the power away from SessionStorage.
  J
 
  Speaking from experience, I have been using localStorage in my PhD
  thesis work w/o any real need for structured clones (I would have used
  Web Database but it isn't widely used yet and I was not sure if it was
  going to make the cut in the end). All it took to come close to
  simulating structured clones now was to develop my own compatibility
  wrapper for localStorage (http://realstorage.googlecode.com for those
  who care) and add setJSONObject() and getJSONObject() methods on the
  wrapper. Works w/o issue.

 Actually, this seems like a prime reason *to* add structured storage
 support. Obviously string data wasn't enough for you so you had to
 write extra code in order to work around that. If structured clones
 had been natively supported you both would have had to write less
 code, and the resulting algorithms would have been faster. Faster
 since the browser can serialize/parser to/from a binary internal
 format faster than to/from JSON through the JSON serializer/parser.

 Yes, but since LocalStorage is already widely deployed, authors are stuck
 with the the structured clone-less version of LocalStorage for a very long
 time.  So the only way an app can store anything that can't be JSONified is
 to break backwards compatibility.



 On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote:
  What are the use cases for wanting to store data beyond strings (and
  what
  can be serialized into strings) in LocalStorage?  I can't think of any
  that
  outweigh the negatives:
  1)  From previous threads, I think it's fair to say that we can all
  agreed
  that LocalStorage is a regrettable API (mainly due to its synchronous
  nature).  If so, it seems that making it more powerful and thus more
  attractive to developers is just asking for trouble.  After all, the
  more
  people use it, the more lock contention there'll be, and the more
  browser UI
  jank users will be sure to experience.  This will also be worse because
  it'll be easier for developers to store large objects in LoaclStorage.
  2)  As far as I can tell, there's no where else in the spec where you
  have
  to serialize structured clone(able) data to disk.  Given that
  LocalStorage
  is supposed to throw an exception if any ImageData is contained and
  since
  File and FileData objects are legal, it seems as though making
  LocalStorage
  handle structured clone data has a fairly high cost to implementors.
   Not to
  mention that disallowing ImageData in only this one case is not
  intuitive.
  I think allowing structured clone(able) data in LocalStorage is a big
  mistake.  Enough so that, if SessionStorage and LocalStorage can't
  diverge
  on this issue, it'd be worth taking the power away from SessionStorage.

 Despite localStorage unfortunate locking contention problem, it's
 become quite a popular API. It's also very successful in terms of
 browser deployment since it's available in at least latest versions of
 IE, Safari, Firefox, and Chrome. Don't know about support in Opera?

 The more popular it becomes, the more it's going to hurt UA developers, web
 developers, and users.  I don't see why this is an argument for making it
 more powerful.

How will it hurt 

Re: [whatwg] Structured clone algorithm on LocalStorage

[Darin Fisher]

On Wed, Sep 23, 2009 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Wed, Sep 23, 2009 at 3:29 PM, Jeremy Orlow jor...@chromium.org wrote:
  On Wed, Sep 23, 2009 at 3:15 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Sep 23, 2009 at 2:53 PM, Brett Cannon br...@python.org wrote:
   On Wed, Sep 23, 2009 at 13:35, Jeremy Orlow jor...@chromium.org
 wrote:
   What are the use cases for wanting to store data beyond strings (and
   what
   can be serialized into strings) in LocalStorage?  I can't think of
 any
   that
   outweigh the negatives:
   1)  From previous threads, I think it's fair to say that we can all
   agreed
   that LocalStorage is a regrettable API (mainly due to its synchronous
   nature).  If so, it seems that making it more powerful and thus more
   attractive to developers is just asking for trouble.  After all, the
   more
   people use it, the more lock contention there'll be, and the more
   browser UI
   jank users will be sure to experience.  This will also be worse
 because
   it'll be easier for developers to store large objects in
 LoaclStorage.
   2)  As far as I can tell, there's no where else in the spec where you
   have
   to serialize structured clone(able) data to disk.  Given that
   LocalStorage
   is supposed to throw an exception if any ImageData is contained and
   since
   File and FileData objects are legal, it seems as though making
   LocalStorage
   handle structured clone data has a fairly high cost to implementors.
Not to
   mention that disallowing ImageData in only this one case is not
   intuitive.
   I think allowing structured clone(able) data in LocalStorage is a big
   mistake.  Enough so that, if SessionStorage and LocalStorage can't
   diverge
   on this issue, it'd be worth taking the power away from
 SessionStorage.
   J
  
   Speaking from experience, I have been using localStorage in my PhD
   thesis work w/o any real need for structured clones (I would have used
   Web Database but it isn't widely used yet and I was not sure if it was
   going to make the cut in the end). All it took to come close to
   simulating structured clones now was to develop my own compatibility
   wrapper for localStorage (http://realstorage.googlecode.com for those
   who care) and add setJSONObject() and getJSONObject() methods on the
   wrapper. Works w/o issue.
 
  Actually, this seems like a prime reason *to* add structured storage
  support. Obviously string data wasn't enough for you so you had to
  write extra code in order to work around that. If structured clones
  had been natively supported you both would have had to write less
  code, and the resulting algorithms would have been faster. Faster
  since the browser can serialize/parser to/from a binary internal
  format faster than to/from JSON through the JSON serializer/parser.
 
  Yes, but since LocalStorage is already widely deployed, authors are stuck
  with the the structured clone-less version of LocalStorage for a very
 long
  time.  So the only way an app can store anything that can't be JSONified
 is
  to break backwards compatibility.
 
 
 
  On Wed, Sep 23, 2009 at 3:11 PM, Jonas Sicking jo...@sicking.cc wrote:
 
  On Wed, Sep 23, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org
 wrote:
   What are the use cases for wanting to store data beyond strings (and
   what
   can be serialized into strings) in LocalStorage?  I can't think of any
   that
   outweigh the negatives:
   1)  From previous threads, I think it's fair to say that we can all
   agreed
   that LocalStorage is a regrettable API (mainly due to its synchronous
   nature).  If so, it seems that making it more powerful and thus more
   attractive to developers is just asking for trouble.  After all, the
   more
   people use it, the more lock contention there'll be, and the more
   browser UI
   jank users will be sure to experience.  This will also be worse
 because
   it'll be easier for developers to store large objects in LoaclStorage.
   2)  As far as I can tell, there's no where else in the spec where you
   have
   to serialize structured clone(able) data to disk.  Given that
   LocalStorage
   is supposed to throw an exception if any ImageData is contained and
   since
   File and FileData objects are legal, it seems as though making
   LocalStorage
   handle structured clone data has a fairly high cost to implementors.
Not to
   mention that disallowing ImageData in only this one case is not
   intuitive.
   I think allowing structured clone(able) data in LocalStorage is a big
   mistake.  Enough so that, if SessionStorage and LocalStorage can't
   diverge
   on this issue, it'd be worth taking the power away from
 SessionStorage.
 
  Despite localStorage unfortunate locking contention problem, it's
  become quite a popular API. It's also very successful in terms of
  browser deployment since it's available in at least latest versions of
  IE, Safari, Firefox, and Chrome. Don't know about support in Opera?