[whatwg] Asynchronous database API feedback

[Dimitri Glazkov]

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<