- From: Simon Harper <simon.harper@manchester.ac.uk>
- Date: Tue, 3 Mar 2009 09:07:35 +0000
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: "UAWG list" <w3c-wai-ua@w3.org>
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 UTC