[whatwg] Worker feedback

On Fri, Mar 27, 2009 at 6:23 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> Another use case would be keeping track of what has been done so far, for
> this I guess it would make sense to have a localStorage API for shared
> workers (scoped to their name). I haven't added this yet, though.


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).



>
>
> > > > Gears had an explicit permissions variable applications could check,
> > > > which seems valuable - do we do anything similar elsewhere in HTML5
> > > > that we could use as a model here?
> > >
> > > HTML5 so far has avoided anything that requires explicit permission
> > > grants, because they are generally a bad idea from a security
> > > perspective (users will grant any permissions the system asks them
> > > for).
> >
> > The Database spec has a strong implication that applications can request
> > a larger DB quota, which will result in the user being prompted for
> > permission either immediately, or at the point that the default quota is
> > exceeded. So it's not without precedent, I think. Or maybe I'm just
> > misreading this:
> >
> > User agents are expected to use the display name and the estimated
> > database size to optimize the user experience. For example, a user agent
> > could use the estimated size to suggest an initial quota to the user.
> > This allows a site that is aware that it will try to use hundreds of
> > megabytes to declare this upfront, instead of the user agent prompting
> > the user for permission to increase the quota every five megabytes.
>
> There are many ways to expose this, e.g. asynchronously as a drop-down
> infobar, or as a pie chart showing the disk usage that the user can click
> on to increase the allocaton whenever they want, etc.


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.


> Re: cookies
> I suppose that network activity should also wait for the lock. I've made
> that happen.
>

Seems like that would restrict parallelism between network loads and
executing javascript, which seems like the wrong direction to go.

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.


>
>
> > Cookies have a cross-domain aspect (multiple subdomains can share cookie
> > state at the top domain) - does this impact the specification of the
> > storage mutex since we need to lockout multiple domains?
>
> There's only one lock, so that should work fine.
>

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.

-atw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090330/7799062c/attachment-0001.htm>

Received on Monday, 30 March 2009 11:22:29 UTC