[whatwg] Worker feedback

I know I said I would stay out of this conversation, but I feel obliged to
share a data point that's pertinent to our API design.
The structured storage spec has an asynchronous API currently. There are no
shortage of experienced javascript programmers at Google, and yet the single
biggest piece of feedback I've gotten from the internal app community has
been (essentially): "The asynchronous APIs are too cumbersome. We are going
to delay porting over to use the HTML5 APIs until we have synchronous APIs,
like the ones in Gears".

So, we should all take the whining of pampered Google engineers with a grain
of salt :), but the point remains that even though callbacks are
conceptually familiar and "easy to use", it's not always convenient (or
possible!) for an application to stop an operation in the middle and resume
it via an asynchronous callback. Imagine if you're a library author that
exposes a synchronous API for your clients - now you'd like to use
localStorage within your library, but there's no way to do it while
maintaining your existing synchronous APIs.

If we try to force everyone to use asynchronous APIs to access local
storage, the first thing everyone is going to do is build their own
write-through caching wrapper objects around local storage to give them
synchronous read access and lazy writes, which generates precisely the type
of racy behavior we're trying to avoid.

If we can capture the correct behavior using synchronous APIs, we should.

-atw

On Fri, Apr 3, 2009 at 11:44 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

> On Thu, Apr 2, 2009 at 8:37 PM, Robert O'Callahan <robert at ocallahan.org>
> wrote:
> > I agree it would make sense for new APIs to impose much greater
> constraints
> > on consumers, such as requiring them to factor code into transactions,
> > declare up-front the entire scope of resources that will be accessed, and
> > enforce those restrictions, preferably syntactically --- Jonas'
> asynchronous
> > multi-resource-acquisition callback, for example.
>
> Speaking as a novice javascript developer, this feels like the
> cleanest, simplest, most easily comprehensible way to solve this
> problem.  We define what needs to be locked all at once, provide a
> callback, and within the dynamic context of the callback no further
> locks are acquirable.  You have to completely exit the callback and
> start a new lock block if you need more resources.
>
> This prevents deadlocks, while still giving us developers a simple way
> to express what we need.  As well, callbacks are at this point a
> relatively novice concept, as every major javascript library makes
> heavy use of them.
>
> ~TJ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090403/000f9ad2/attachment.htm>

Received on Friday, 3 April 2009 14:25:54 UTC