<div class="gmail_quote"><div>Sorry for breaking the continuity of this thread, but since the original topic was never really resolved, I wanted to jump back a bit.<br><br><br>Since my original post, I've continued thinking about LocalStorage, structured clones, etc...and the more I've thought about it, the more convinced I am that adding such support is a big mistake.  One way to think about it is as follows:<br>


<br>1)  We've all pretty much agreed that localStorage's synchronous design was a mistake that we should be careful to not repeat.<br>2)  I think we can all agree that storing structured clone data makes LocalStorage more powerful and useful to developers.<br>


3)  And I think we can all agree that developers like to use more powerful APIs.  Especially when the API is easy to use and understand (as LocalStorage is).<br>4)  Lock contention becomes worse as the frequency of acquires and/or the duration the lock is held increases.<br>


<br>Although there might be some subtleties about the statements I made that people could argue with, I think all these statements are pretty fundamentally true.  Assuming so, it's not a stretch to see that 2 and 3 imply that adding structured clones to local storage will lead to more use of local storage.  If use increases, then 4 implies that the storage lock is going to become a bigger problem over time.  Since we can all agree that the synchronous design of local storage is already a problem that we wish we had avoided, I just can't understand why we're happy to make it a bigger problem.<br>


<br>Does anyone have an argument against this?<br><br><br>Personally I find this argument especially compelling for the following reason:  Anyone who's going to use LocalStorage in the near to medium future will need to handle the case of LocalStorage only handling strings.  This is because structured clones supports a super-set of what can be serialized within a script, there's no way for libraries to build a transparent compatibility abstraction.  Thus, for some time, developers will either need to only use data that can be serialized (thus making structured clones only a performance optimization) or developers will need to cut off browsers that don't support structured clones.<br>


<br>Assuming that,  we're basically saying that structured clones is a feature for the long term use and health of LocalStorage.  Now I know that we can't just get rid of LocalStorage and coming up with viable alternatives will take some time, but do we really believe that we can't agree on and develop a better alternative in the mean time?<br>


<br><br>I'm fine with SessionStorage supporting structured clones.  I just don't think we should make LocalStorage any more powerful.  In fact, at this point, I think we should redirect all the time and effort we're putting into making LocalStorage better (including solving lock contention issues) and instead put it into creating a new API that solves these problems and that all the browser vendors can get behind.  (If you have ideas on how I can get this ball rolling, I'd love to hear them!)<br>

<font color="#888888">
<br>J<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#888888"><br></font></font></font></div></div>