On Fri, Sep 4, 2009 at 10:48 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com">michaeln@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

> <span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Shared worker access would be a plus.</span><div><font face="arial, sans-serif"><span style="border-collapse:collapse"><br>
</span></font></div><div><span style="font-size:13px"></span><font face="arial, sans-serif"><span style="border-collapse:collapse">Indeed. The lack of access to LocalStorage in 'workers' forces developers to use the more difficult database api for all storage needs, and to roll their own change event mechanisms (based on postMessage). Thats a bunch of busy work if a name/value pair schema is all your app really needs.</span></font></div>

</blockquote><div> </div><div>For the record, all the developers I've talked to about the current state of AppCache+storage+workers have been VERY disheartened.  IE and Firefox have no intentions of supporting WebDatabase any time soon.  localStorage is not available from workers.  AppCache requires apps to be 100% client based (the server needs to server static pages and the logic must be in JS) if you have any personalization/authentication.  Workers are only accessible via message passing.  Sure, we can imagine ways that nearly every application _can_ be written in such environments, but in many cases these designs are quite different from what web developers are used to.</div>

<div><br></div><div>I think there are good reasons for all the design decisions we're making, but I'm worried we're not looking at the big picture enough.</div></div>