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.<div><br></div><div>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".</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>If we can capture the correct behavior using synchronous APIs, we should.</div><div><br></div><div>-atw</div><div><br><div class="gmail_quote">On Fri, Apr 3, 2009 at 11:44 AM, Tab Atkins Jr. <span dir="ltr"><<a href="mailto:jackalmage@gmail.com">jackalmage@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, Apr 2, 2009 at 8:37 PM, Robert O'Callahan <<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>> wrote:<br>
> I agree it would make sense for new APIs to impose much greater constraints<br>
> on consumers, such as requiring them to factor code into transactions,<br>
> declare up-front the entire scope of resources that will be accessed, and<br>
> enforce those restrictions, preferably syntactically --- Jonas' asynchronous<br>
> multi-resource-acquisition callback, for example.<br>
<br>
</div>Speaking as a novice javascript developer, this feels like the<br>
cleanest, simplest, most easily comprehensible way to solve this<br>
problem. We define what needs to be locked all at once, provide a<br>
callback, and within the dynamic context of the callback no further<br>
locks are acquirable. You have to completely exit the callback and<br>
start a new lock block if you need more resources.<br>
<br>
This prevents deadlocks, while still giving us developers a simple way<br>
to express what we need. As well, callbacks are at this point a<br>
relatively novice concept, as every major javascript library makes<br>
heavy use of them.<br>
<font color="#888888"><br>
~TJ<br>
</font></blockquote></div><br></div>