<br><br><div class="gmail_quote">On Fri, Mar 27, 2009 at 6:23 PM, Ian Hickson <span dir="ltr"><ian@hixie.ch></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Another use case would be keeping track of what has been done so far, for<br>
this I guess it would make sense to have a localStorage API for shared<br>
workers (scoped to their name). I haven't added this yet, though.</blockquote><div><br></div><div>On a related note, I totally understand the desire to protect developers from race conditions, so I understand why we've removed localStorage access from dedicated workers. In the past we've discussed having synchronous APIs for structured storage that only workers can use - it's a much more convenient API, particularly for applications porting to HTML5 structured storage from gears. It sounds like if we want to support these APIs in workers, we'd need to enforce the same kind of serializability guarantees that we have for localStorage in browser windows (i.e. add some kind of structured storage mutex similar to the localStorage mutex).</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
<br>
> > > Gears had an explicit permissions variable applications could check,<br>
> > > which seems valuable - do we do anything similar elsewhere in HTML5<br>
> > > that we could use as a model here?<br>
> ><br>
> > HTML5 so far has avoided anything that requires explicit permission<br>
> > grants, because they are generally a bad idea from a security<br>
> > perspective (users will grant any permissions the system asks them<br>
> > for).<br>
><br>
> The Database spec has a strong implication that applications can request<br>
> a larger DB quota, which will result in the user being prompted for<br>
> permission either immediately, or at the point that the default quota is<br>
> exceeded. So it's not without precedent, I think. Or maybe I'm just<br>
> misreading this:<br>
><br>
> User agents are expected to use the display name and the estimated<br>
> database size to optimize the user experience. For example, a user agent<br>
> could use the estimated size to suggest an initial quota to the user.<br>
> This allows a site that is aware that it will try to use hundreds of<br>
> megabytes to declare this upfront, instead of the user agent prompting<br>
> the user for permission to increase the quota every five megabytes.<br>
<br>
There are many ways to expose this, e.g. asynchronously as a drop-down<br>
infobar, or as a pie chart showing the disk usage that the user can click<br>
on to increase the allocaton whenever they want, etc.</blockquote><div><br></div><div>Certainly. I actually think we're in agreement here - my point is not that you need a synchronous permission grant (since starting up a worker is an inherently asynchronous operation anyway) - just that there's precedent in the spec for applications to request access to resources (storage space, persistent workers) that are not necessarily granted to all sites by default. It sounds like the specifics of how the UA chooses to expose this access control (pie charts, async dropdowns, domain whitelists, trusted zones with security levels) left to the individual implementation.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Re: cookies<br>
I suppose that network activity should also wait for the lock. I've made<br>
that happen.<br>
</blockquote><div><br></div><div>Seems like that would restrict parallelism between network loads and executing javascript, which seems like the wrong direction to go.</div><div><br></div><div>It feels like we are jumping through hoops to protect running script from having document.cookies modified out from underneath it, and now some of the ramifications may have real performance impacts. From a pragmatic point of view, I just want to remind people that many current browsers do not make these types of guarantees about document.cookies, and yet the tubes have not imploded.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
> Cookies have a cross-domain aspect (multiple subdomains can share cookie<br>
> state at the top domain) - does this impact the specification of the<br>
> storage mutex since we need to lockout multiple domains?<br>
<br>
There's only one lock, so that should work fine.<br>
</blockquote><div><br></div><div>OK, I was assuming a single per-domain lock (ala localStorage) but it sounds like there's a group lock, cross-domain. This makes it even more onerous if network activity across all related domains has to serialize on a single lock. </div>
<div> </div><div>-atw</div></div><br>