Michael Davidson wrote:
...
WHY NOT SHARED WORKERS
Shared workers and persistent workers are designed to solve similar
problems, but don't meet our needs. The key difference between what
we're proposing and earlier proposals for persistent workers is that
background pages would be able to launch visible windows and have full
DOM access. This is different from the model of workers where all
interaction with the DOM has to be done through asynchronous message
passing. We would like background pages to be able to drive UI in a
visible window using the techniques (DOM manipulation, innerHTML) that
are common today. We believe that more apps would be able to take
advantage of a background page if they didn't require rewriting the
app in the asynchronous, message-passing style required by workers.
hmmm ... this is the worrying part to me. Sounds like one of the
presumed qualities of web workers, ease of use, isn't going to be met
with the currently spec'd APIs. Is there some way to framework-ize
something around the current APIs to make this easier to use by
developers? Or would the addition of a synchronous API help (assuming
some non-evil synchronous API)? Or do we need a lot of head shaping
around asynchronous message sending?
Futher question would be whether there are two issues: dealing with
asynchronous messages, and direct DOM API. If we could get over the
hurdle of the async, do we still need the direct DOM API?
--
Patrick Mueller - http://muellerware.org
