W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2008

Re: Worker Threads and Site Security Policy | Two Possible New Items for Standardization

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 25 Jun 2008 15:12:59 -0700
Message-ID: <4862C2EB.8060101@sicking.cc>
To: Maciej Stachowiak <mjs@apple.com>
CC: arun@mozilla.com, Ian Hickson <ian@hixie.ch>, aa@google.com, Ben Turner <bturner@mozilla.com>, Johnny Stenback <jst@mozilla.com>, Jonas Sicking <sicking@mozilla.com>, Brandon Sterne <bsterne@mozilla.com>, chaals@opera.com, chris.wilson@microsoft.com, public-webapps@w3.org, schepers@w3.org, tlr@w3.org, dveditz@mozilla.com

Maciej Stachowiak wrote:
> 
> 
> On Jun 25, 2008, at 1:09 PM, Arun Ranganathan wrote:
> 
>> Doug Schepers, Charles McCathieNevile (Chairs), Members of the WG,
>>
>> On behalf of Mozilla, I'd like to introduce the possibility of two new 
>> work items for this group to consider.  Neither of these is presented 
>> as a fait accompli, although we would like to consider both of these 
>> for inclusion in Firefox 3.Next if that is possible.
>>
>> 1. Worker Threads in Script.  The idea is to offer developers the 
>> ability to spawn threads from within web content, as well as 
>> cross-thread communication mechanisms such as postMessage.  Mozilla 
>> presents preliminary thought on the subject [1], and notes similar 
>> straw persons proposed by WHATWG [2] and by Google Gears [3].  Also 
>> for reference see worker threads in C# [4].  The Web Apps working 
>> group seems like a logical home for this work.  Will other members of 
>> the WG engage with Mozilla on this, via additional work items covered 
>> by the charter of this WG?
> 
> Apple is interested in a worker API. The key issues for workers, in my 
> opinion, are security, messaging, and which of the normal APIs are 
> available. Right now, these things are covered in HTML5, so I think that 
> may be a better place to add a Worker API.
> 
> We would certainly like to coordinate our work in this area with the 
> proposed APIs cited.

I'd really rather not add more stuff to HTML5, it's too big as it is. 
Ideally worker threads is something that we can nail down in a pretty 
short period of time, before HTML5 is out (targeted a few years into the 
future iirc).

Like you say, some features from HTML5 should be exposed in the context 
of worker threads. I don't really know how to handle that, but I can see 
two ways:

1. Make a informative note stating a list of features that we expect 
will be made available once there is a finished spec for them, but leave 
it up to the HTML5 spec to actually explicitly make this requirement.

2. Have a normative requirement that implementations that also support 
feature X from HTML5, makes that implementation available to the worker 
thread as well.

/ Jonas
Received on Wednesday, 25 June 2008 22:13:25 GMT

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