Web Workers

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.

===

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

Received on Monday, 2 March 2009 16:11:34 UTC