W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: LCWD comments

From: Drew Wilson <atwilson@google.com>
Date: Thu, 1 Jul 2010 12:56:39 -0700
Message-ID: <AANLkTimTbWNXYBv4xZSsIWui9eOTzD_zEDsA6W4OLxwF@mail.gmail.com>
To: Krzysztof Maczyński <1981km@gmail.com>
Cc: public-webapps@w3.org
On Wed, Jun 30, 2010 at 7:08 PM, Krzysztof Maczyński <1981km@gmail.com>wrote:

>
> 11. In [c]:
> > there is no way to override the type. It's always assumed to be
> JavaScript.
> This is a violation of orthogonality for no real benefit.
>

I know that the NativeClient team has experimented with supporting native
code in workers (in Chrome) in the past, using some fairly ugly hack based
on the suffix of the URL. Having some support for MIME types would enable
something like this in the future without having to resort to those hacks.


>
> 12. In [c]:
> > If there are any outstanding transactions that have callbacks
> What's a transaction, when has it got a callback?
>

I believe this refers to DB APIs (WebSQLDatabase, IndexedDB [
http://www.w3.org/TR/IndexedDB/]) that might be exposed to workers.


>
> > Thus, scripts must be external files with the same scheme as the original
> page: you can't load a script from a data: URL
> Why impose this restriction? Is it that exceptions to same-origin policy
> when it's still new would be confusing for specifiers and the audience, so
> this possibility is postponed to the next version? In any case, I suggest
> allowing workers to be instantiated with Function objects (whatever this may
> be in language bindings, given positive resolution of 11) as well. Including
> workers directly inline seems natural in many scenarios.
>

Agreed that data URLs would be useful. My recollection is that they are
currently prohibited because the script URL is used to derive the security
context for that worker (rather than inheriting it from the parent) which
I've never entirely understood.

I don't see how we can expose Function objects since the execution context
of workers are distinct from the execution context of the main page.

For example:

my_global = 123;
function worker_script() {
 do_something(my_global);
}
new Worker(worker_script);

What does worker_script do when it accesses my_global? It certainly can't
have the global scope of the parent page in its scope chain. There's a
slightly longer discussion of that topic here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024576.html
Received on Thursday, 1 July 2010 19:57:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT