- From: Brady Eidson <beidson@apple.com>
- Date: Mon, 10 Dec 2007 13:43:32 -0800
On Dec 10, 2007, at 12:21 PM, Geoffrey Garen wrote: >> I still feel that there are many simple use cases for a local >> database >> for which a developer can assume the read and write latency should >> always be less than five seconds. > > 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. > > Under what conditions can a web developer assume that no other > processes are using the hard drive? > > 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? > >> If we cannot provide this, I feel that localstorage will not be >> successful, so it won't matter what API it uses. > > 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 :). > > Anyway, if an API without synchronous access turns out to be > unpopular, we can always add synchronous access later. Whereas, if > an API with synchronous access turns out to hang the browser and > make web sites unreliable, we can't remove it later. So I think it's > more prudent to leave synchronous access out, and see what happens. I am copying Geoff's reply here, in its entirety, without added commentary*, to stress how much I agree with every point he makes. On Dec 10, 2007, at 12:38 PM, Oliver Hunt wrote: > 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.. To take this point and expand it... 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. ~Brady * - I did bold a few points, this might qualify as "commentary" - my apologies :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20071210/21c07b35/attachment.htm>
Received on Monday, 10 December 2007 13:43:32 UTC