<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 10, 2007, at 12:21 PM, Geoffrey Garen wrote:</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><blockquote type="cite">I still feel that there are many simple use cases for a local database<br></blockquote><blockquote type="cite">for which a developer can assume the read and write latency should<br></blockquote><blockquote type="cite">always be less than five seconds.<br></blockquote><br>Even the fastest desktop hard drives can show greater than 5 seconds of latency under heavy load -- for example, while the user is compiling, while Spotlight or Google Desktop is indexing the hard drive, while many apps are starting up at the same time, etc. As long as enough requests are pending in the OS's or the drive's read/write queue, the browser has to wait.<br><br>Under what conditions can a web developer assume that no other processes are using the hard drive?<br><br>I'd hate for GMail to mysteriously stop working every couple of days just because of some background process that I had no knowledge of. As a developer, how would you debug such a problem? As a tech support worker, how would you explain it to an end user?<br><br><blockquote type="cite">If we cannot provide this, I feel that localstorage will not be successful, so it won't matter what API it uses.<br></blockquote><br>I think this is a pretty extreme conclusion. My impression is that web developers want local storage so badly, they'll use whatever API we give them -- even if it's in Haskell :).<br><br>Anyway, <b>if</b> an API without synchronous access turns out to be unpopular, we can always <b>add synchronous access later</b>. Whereas, if an API with synchronous access turns out to hang the browser and make web sites unreliable, we <b>can't remove it later</b>. So I think it's more prudent to leave synchronous access out, and see what happens.<br></blockquote><br></div><div>I am copying Geoff's reply here, in its entirety, without added commentary*, to stress how much I agree with every point he makes.</div><div><br></div><div><div>On Dec 10, 2007, at 12:38 PM, Oliver Hunt wrote:</div><div><br class="webkit-block-placeholder"></div><blockquote type="cite">Also making the assumption that local storage will always be local is flawed as that assumes that no one uses roaming profiles -- if you were to require that local storage always use a local device, you are effectively meaning many corporate users would be unable to use websites that make use of the API, or even worse occasionally the site will work, and occasionally it won't, and sometimes it won't have all your data..</blockquote><div><br class="webkit-block-placeholder"></div>To take this point and expand it...</div><div><br class="webkit-block-placeholder"></div><div>We're calling this "local storage" when in reality it is "client side storage" - this means the data belongs to the client machine's environment and not the server's environment. The form the storage takes client-side is entirely up to the user agent and the client. Making any assumptions beyond "this data belongs to and is managed by the client machine's environment" is beyond the privilege of the web developer or server administrator.</div><div><br class="webkit-block-placeholder"></div><div>~Brady</div><div><br class="webkit-block-placeholder"></div><div>* - I did bold a few points, this might qualify as "commentary" - my apologies :)</div></body></html>