- From: Dimitri Glazkov <dimitri.glazkov@gmail.com>
- Date: Mon, 10 Dec 2007 21:22:34 -0600
On Dec 10, 2007 2:38 PM, Oliver Hunt <oliver at apple.com> wrote: > > On 10/12/2007, at 12:21 PM, Geoffrey Garen wrote: > >> 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 :) . > > Hey don't knock Haskell ;) > > More seriously though, making assumptions about IO performance is never > a good idea -- what happens if the IO is to a low budget/resource device > -- say a handheld or something that uses sdcard storage (which iirc have > slow IO) -- or any form of external storage for that matter? These are > devices that tend to be low power high latency, typically they are slow > to begin with, if you then start putting even slower *blocking* > behaviour it could render any site using the API unusable on such a device. > > 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.. Guys, I think the point was that it's not unreasonable to have synchronous API. The argument about slow/busy devices is valid, but I still think the developer should have the choice of either going with a simple query/receive calls in their code as opposed to braving complexity of asynchronous API. I fully agree with this point and do believe that if it's a low-hanging fruit, it should be included into the implementation. Furthermore, I am biased, but think that threading model in Gears is a pretty good approach to this problem. Instead of building the asynchronous (and complex) database API, offer a simple worker pool API and a simple synchronous database API. :DG<
Received on Monday, 10 December 2007 19:22:34 UTC