<div class="gmail_quote">On Mon, Oct 12, 2009 at 7:07 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>></span> wrote:<br><div>... </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
> the problem here is that localStorage is a pile of global variables.<br>
> we are trying to give people global variables without giving them tools<br>
> to synchronize access to them. the claim i've heard is that developers<br>
> are not savy enough to use those tools properly. i agree that<br>
> developers tend to use tools without fully understanding them. ok, but<br>
> then why are we giving them global variables?<br>
<br>
The global variables have implicit locks such that you can build the tools<br>
for explicit locking on top of them:<br>
<br>
// run this first, in one script block<br>
var id = localStorage['last-id'] + 1;<br>
localStorage['last-id'] = id;<br>
localStorage['email-ready-' + id] = "0"; // "begin"<br>
<br>
// these can run each in separate script blocks as desired<br>
localStorage['email-subject-' + id] = subject;<br>
localStorage['email-from-' + id] = from;<br>
localStorage['email-to-' + id] = to;<br>
localStorage['email-body-' + id] = body;<br>
<br>
// run this last<br>
localStorage['email-ready-' + id] = "1"; // "commit"<br>
<br></blockquote><div><br></div><div>Dividing up work like this into separate SCRIPT elements to scope the</div><div>locking seems really awkward to me.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On Thu, 24 Sep 2009, Darin Fisher wrote:<br>
><br>
> The current API exposes race conditions to the web. The implicit<br>
> dropping of the storage lock is that. In Chrome, we'll have to drop an<br>
> existing lock whenever a new lock is acquired. That can happen due to a<br>
> variety of really odd cases (usually related to nested loops or nested<br>
> JS execution), which will be difficult for developers to predict,<br>
> especially if they are relying on third-party JS libraries.<br>
><br>
> This issue seems to be discounted for reasons I do not understand.<br>
<br>
You can only lose the lock in very specific conditions. Those conditions<br>
are rarely going to interact with code that actually does storage work in<br>
a way that relies on the lock:<br>
<br>
- changing document.domain<br>
- history.back(), .forward(), .go(n)<br>
- invoking a plugin<br>
- alert(), confirm(), prompt(), print()<br>
- showModalDialog()<br>
- yieldForStorageUpdates()<br>
<br>
I discussed this in more detail here:<br>
<br>
<a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html</a><br>
<br></blockquote><div><br></div><div>You are right that the conditions are specific, but I don't know that that is the</div><div>exhaustive list. Rather than defining unlock points, I would implement implicit</div><div>
unlocking by having any nested attempt to acquire a lock cause the existing lock</div><div>to be dropped. Nesting can happen in the cases you mention, but depending on</div><div>the UA, it may happen for other reasons too.</div>
<div><br></div><div>This combined with the fact that most people use JS libraries means that the</div><div>coder is not going to have an easy time knowing when these specific conditions</div><div>are met. I don't think defining a set of allowed unlock points is sufficient to make</div>
<div>this API not be a minefield for users.</div><div><br></div><div>For example, a JS library might evolve to use flash for something small (like</div><div>storage or sound) that it previously didn't use when I first developed my code.</div>
<div>Voila, now my storage lock is released out from under me.</div><div><br></div><div>At this point, I'm not favoring implementing the storage mutex in Chrome. I</div><div>don't think we will have it in our initial implementation of LocalStorage. I think</div>
<div>web developers that care will have to find another way to manage locking, like</div><div>using a Web Database transaction or coordinating with a Shared Worker.</div><div><br></div><div>Sorry to be a grump about this, but a cross-process lock that lasts until JS</div>
<div>returns is just going to slow down the web. It is a really bad idea for that</div><div>reason.</div><div><br></div><div>-Darin</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
On Tue, 8 Sep 2009, Chris Jones wrote:<br>
><br>
> Can those in the first camp explain why "mutex" semantics is better than<br>
> "transaction" semantics? And why it's desirable to have one DB spec<br>
> specify "transaction" semantics (Web Database) and a second specify<br>
> "mutex" semantics (localStorage)?<br>
<br>
I don't think it's desirable. It's just what we have, though an accident<br>
of history.<br>
<br>
<br>
Where we're at: localStorage can't really change. It is what it is.<br>
<br>
We have a better proposal, Web Database, but not everybody wants to<br>
implement it.<br>
<br>
To move forward, I would recommend that someone come up with a storage<br>
proposal with the following characteristics:<br>
<br>
* All major browsers vendors are willing to implement it.<br>
* Compatible with workers.<br>
* Doesn't have any race conditions.<br>
* Doesn't involve a cross-process mutex that blocks interaction.<br>
* Stores structured data.<br>
* Can be queried in arbitrary ways.<br>
* Doesn't expose authors to locking primitives.<br>
<br>
Then we can replace Web Database with it and we can move on.<br>
<br>
I suggest that the right venue for this discussion would be the W3C Web<br>
Apps group, at <a href="mailto:public-webapps@w3.org">public-webapps@w3.org</a>.<br>
<br>
<br>
On Wed, 9 Sep 2009, Darin Fisher wrote:<br>
><br>
> What about navigating an iframe to a reference fragment, which could<br>
> trigger a scroll event? The scrolling has to be done synchronously for<br>
> compat with the web.<br>
<br>
You can only do that with same-domain pages, as far as I can tell.<br>
<br>
(Does that really have to be synchronous? Right now we don't define the<br>
'scroll' event anywhere. What are the semantics it needs?)<br>
<br>
<br>
On Mon, 31 Aug 2009, James Graham wrote:<br>
> Quoting Ian Hickson <<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>>:<br>
> ><br>
> > We can't treat cookies and persistent storage differently, because<br>
> > otherwise we'll expose users to cookie resurrection attacks.<br>
> > Maintaining the user's expectations of privacy is critical.<br>
><br>
> I think the paragraph under "treating persistent storage as cookies"<br>
> should simply be removed. The remainder of that section already does an<br>
> adequate job of explaining the privacy implications of persistent<br>
> storage. The UI should be entirely at the discretion of the browser<br>
> vendor since it involves a variety of tradeoffs, with the optimum<br>
> solution depending on the anticipated user base of the browser. Placing<br>
> spec requirements simply limits the abilities of browser vendors to find<br>
> innovative solutions to the problem. In addition, since there is no<br>
> interoperability requirement here, using RFC 2119 language seems<br>
> inappropriate; especially since the justification given is rather weak<br>
> ("this might encourage users?") and not supported by any evidence.<br>
<br>
I think it's important to include this paragraph in a discussion of the<br>
privacy implications of these APIs. I feel like it would be irresponsible<br>
of me to not include this text, given how important this actually is.<br>
<br>
<br>
> As to what browser vendors should actually _do_, it seems to me that the<br>
> "user's expectations of privacy" is actually an illusion in this case;<br>
> all the bad stuff that can be done with persistent storage can already<br>
> be done using a variety of techniques. Trying to fix up this one case<br>
> seems like closing the stable door after the horse has bolted. Therefore<br>
> the "delete local storage when you delete cookies" model seems flawed,<br>
> particularly as it can lead to the type of problem that Jens described<br>
> above.<br>
<br>
Cookie resurrection has been a real concern on the Web. I don't think it's<br>
an illusion.<br>
<br>
<br>
> On a slightly different topic, it is unclear what the relationship<br>
> between the statement in section 4.3 "User agents should expire data<br>
> from the local storage areas only for security reasons or when requested<br>
> to do so by the user" and the statement in section 6.1 "User agents may<br>
> automatically delete stored data after a period of time." is supposed to<br>
> be. Does the latter count as a security reason?<br>
<br>
I've edited the latter text to indicate that the expiration should only be<br>
done at user option.<br>
<br>
<br>
On Fri, 2 Oct 2009, Jeremy Orlow wrote:<br>
><br>
> Since my original post, I've continued thinking about LocalStorage,<br>
> structured clones, etc...and the more I've thought about it, the more<br>
> convinced I am that adding such support is a big mistake. One way to<br>
> think about it is as follows:<br>
><br>
> 1) We've all pretty much agreed that localStorage's synchronous design<br>
> was a mistake that we should be careful to not repeat.<br>
><br>
> 2) I think we can all agree that storing structured clone data makes<br>
> LocalStorage more powerful and useful to developers.<br>
><br>
> 3) And I think we can all agree that developers like to use more<br>
> powerful APIs. Especially when the API is easy to use and understand<br>
> (as LocalStorage is).<br>
><br>
> 4) Lock contention becomes worse as the frequency of acquires and/or<br>
> the duration the lock is held increases.<br>
><br>
> Although there might be some subtleties about the statements I made that<br>
> people could argue with, I think all these statements are pretty<br>
> fundamentally true. Assuming so, it's not a stretch to see that 2 and 3<br>
> imply that adding structured clones to local storage will lead to more<br>
> use of local storage.<br>
<br>
I don't see why it would add significantly more use. Once a site is using<br>
localStorage, whether it has structured storage natively or not, they're<br>
going to store structured data in it -- e.g. using JSON, as some people<br>
have said they already are -- and so I don't think that this effectively<br>
increases the usage. It just makes it simpler for those who do use it.<br>
<br>
<br>
> If use increases, then 4 implies that the storage lock is going to<br>
> become a bigger problem over time. Since we can all agree that the<br>
> synchronous design of local storage is already a problem that we wish we<br>
> had avoided, I just can't understand why we're happy to make it a bigger<br>
> problem.<br>
><br>
> Does anyone have an argument against this?<br>
<br>
I don't think it makes it a significantly bigger problem.<br>
<br>
<br>
> Anyone who's going to use LocalStorage in the near to medium future will<br>
> need to handle the case of LocalStorage only handling strings. This is<br>
> because structured clones supports a super-set of what can be serialized<br>
> within a script, there's no way for libraries to build a transparent<br>
> compatibility abstraction. Thus, for some time, developers will either<br>
> need to only use data that can be serialized (thus making structured<br>
> clones only a performance optimization) or developers will need to cut<br>
> off browsers that don't support structured clones.<br>
><br>
> Assuming that, we're basically saying that structured clones is a<br>
> feature for the long term use and health of LocalStorage. Now I know<br>
> that we can't just get rid of LocalStorage and coming up with viable<br>
> alternatives will take some time, but do we really believe that we can't<br>
> agree on and develop a better alternative in the mean time?<br>
<br>
I think it makes sense to allow Files to be stored today.<br>
<br>
However, I'm all for a better API. So if you can get people to agree to a<br>
better API before anyone ships this one and before pages start depending<br>
on it, then maybe we can remove the structured storage feature from<br>
localStorage.<br>
<br>
<br>
> I'm fine with SessionStorage supporting structured clones. I just don't<br>
> think we should make LocalStorage any more powerful. In fact, at this<br>
> point, I think we should redirect all the time and effort we're putting<br>
> into making LocalStorage better (including solving lock contention<br>
> issues) and instead put it into creating a new API that solves these<br>
> problems and that all the browser vendors can get behind. (If you have<br>
> ideas on how I can get this ball rolling, I'd love to hear them!)<br>
<br>
I agree.<br>
<font color="#888888"><br>
--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>