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

On Jun 25, 2008, at 3:12 PM, Jonas Sicking wrote:

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

I am ok with the spec either being in HTML5 or standalone, but we have  
to realize that if it is a separate spec, it will have dependencies on  
HTML5. For XMLHttpRequest this has turned out to be controversial, so  
we should make this clear up front.

Regards,
Maciej

Received on Wednesday, 25 June 2008 22:37:23 UTC