W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2009

Re: Web Workers

From: Simon Harper <simon.harper@manchester.ac.uk>
Date: Tue, 3 Mar 2009 09:07:35 +0000
Message-Id: <DD0064DD-B387-4280-A9A0-9BD4E2DD1677@manchester.ac.uk>
Cc: "UAWG list" <w3c-wai-ua@w3.org>
To: Charles McCathieNevile <chaals@opera.com>
Thanks for this Chaals,

Jim if the the group agrees maybe we can pursue this as Chaals suggests.

Cheers
Si.

=======================

Simon Harper
University of Manchester (UK)

Human Centred Web Lab: http://hcw.cs.manchester.ac.uk

My Site: http://hcw.cs.manchester.ac.uk/people/harper/
My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ 
phpicalendar/week.php

My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/harper/ 
SimonHarper.ics





On 2 Mar 2009, at 16:53, Charles McCathieNevile wrote:

> On Mon, 02 Mar 2009 17:10:54 +0100, Simon Harper  
> <simon.harper@manchester.ac.uk> wrote:
>
>> Hi there,
>>
>> week before last I brought up a possible problem as the Web Apps  
>> Working Group wanted to define Web work as "an API that allows Web  
>> application authors to spawn background workers running scripts in  
>> parallel to their main page, allowing for thread-like operation  
>> with message-passing as the coordination mechanism"
>>
>> Jim asked me to see if there any implications or possibilityfor  
>> implications, and bring it back to the group. I think that we're  
>> OK however from a very early draft on their wiki, things that look  
>> to suggest there is an isolation between worker and agent are:
>>
>> 1) Implementations should not have to expose Node or Document  
>> objects to workers.
>> 2) Workers should not share anything with the outside world. The  
>> objects representing the worker in the worker itself and in the  
>> context that created the worker should be different, for instance.
>>
>> and this one may need more thought
>>
>> 3) Capabilities granting: It should be possible for code running  
>> in one iframe to negotiate a connection to another iframe, with  
>> that connection granting certain rights (e.g. adding to an address  
>> book but not reading from it).
>>
>> The full draft is below but I think it may be useful to get  
>> Charles McCathieNevile from Opera in to talk with us about it if  
>> maybe Henny can ask.
>
> You can ask me directly. I am on this list.
>
> But I am pretty busy and not really an expert myself on Web  
> Workers. I will try to find someone from the Web apps group who you  
> really should ask - Ian Hickson would be good, but is generally  
> loath to go to teleconferences, so I will assume that you will ask  
> him, and look for alternatives.
>
> cheers
>
> Chaals
>
>> ===
>>
>> Full Draft Requirements List
>> 1) Background workers: A Web application needs to keep its data  
>> synchronised with the server, both sending updates to the server  
>> and receiving updates from the server, including handling  
>> buffering of updates for when the application goes offline. The  
>> code to do this would ideally be independent of the UI code.
>> 2) URLs: Workers should be spawned from URLs, not from strings,  
>> since script rarely has access to its own source.
>> 3) Message queuing: Messages sent to a worker before the worker  
>> has initialised should not be lost.
>> 4) Workers should have access to timers.
>> 5) Workers should have access to the network.
>> 6) Workers should be able to use libraries.
>> 7) Implementations should not have to expose Node or Document  
>> objects to workers.
>> 8) Workers should not share anything with the outside world. The  
>> objects representing the worker in the worker itself and in the  
>> context that created the worker should be different, for instance.
>> 9) Shared workers: Multiple instances of the same Web application  
>> would want to keep just one connection back to the server.
>> 10) Capabilities granting: It should be possible for code running  
>> in one iframe to negotiate a connection to another iframe, with  
>> that connection granting certain rights (e.g. adding to an address  
>> book but not reading from it).
>> 11) Delegation: It should be possible for one worker to spawn  
>> another worker and efficiently delagate a request to that worker,  
>> without the caller being aware of the delagate and without the  
>> original worker having to proxy all the messages.
>> 12) Workers whose parents are not longer useful should be killed.  
>> Workers should be able to detect this is about to happen and exit  
>> gracefully.
>>
>>
>> Cheers
>> Si.
>>
>> =======================
>>
>> Simon Harper
>> University of Manchester (UK)
>>
>> Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
>>
>> My Site: http://hcw.cs.manchester.ac.uk/people/harper/
>> My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ 
>> phpicalendar/week.php
>>
>> My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/ 
>> harper/SimonHarper.ics
>>
>>
>>
>>
>>
>
>
>
> -- 
> Charles McCathieNevile  Opera Software, Standards Group
>     je parle franšais -- hablo espa˝ol -- jeg lŠrer norsk
> http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Tuesday, 3 March 2009 09:08:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:52:09 GMT