[whatwg] Declarative web worker creation and communication?

[Fred Andrews]

Hi Andrew,

Thank you for the feedback.  The PUA 'shared context' will likely need to be a
distinct web worker variant to cater for any required restrictions and also to
ensure it does not entangle its specific requirements with other innovations
to web workers.  However the message API may be reusable, and trying to
avoid gratuitous differences seems a worthy goal.

Some concerns (lack of understanding) I have with the Web Worker spec. at:
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html

"9.2.3 The worker's lifetime
... Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o."

Does this mean that the Document object of the caller is made available to be web worker?  I can't see an interface to it?


"9.2.4 Processing model
...
5. A new script is now created, as follows.
...
Set the script's browsing context to owner browsing context.
...
Set the script's document to owner document."

There does not appear to be an API to actually effect the owner browsing context or document?
Is this just laying a foundation for future work?
Are web workers expected to someday be able to cause navigation of the creators browsing context etc?


"9.3 APIs available to workers
...
The DOM APIs (Node objects, Document objects, etc) are not available to workers in this version of this specification."

Are there plans to allow web workers access to the DOM of their creator?

Does this apply to documents created by the web worker, such as via XHR?

Looking at the source code for some implementations will help clarify the current state,
but it would also be of interest to know of planned web workers extensions?

cheers
Fred


> Date: Mon, 5 Nov 2012 10:41:00 +0100
> From: atwilson at google.com
> To: fredandw at live.com
> CC: whatwg at whatwg.org; simonp at opera.com
> Subject: Re: [whatwg] Declarative web worker creation and communication?
> 
> On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews <fredandw at live.com> wrote:
> 
> > Hi Simon,
> >
> > The use I have in mind is a work-in-progress, see:
> > http://www.w3.org/community/pua/wiki/Draft#Examples
> >
> > However the HTML standard already permits a UA to disable JS, and there is
> > the iframe sandbox, or CSP, or browser extensions, to disable JS.  I would
> > like to make any extensions as widely applicable as possible in the hope of
> > building support for them, and think there is a good case for a web
> > application with document JS disabled that can still communicate with web
> > workers to implement AJAX style designs.
> >
> 
> I guess I'm not convinced that a web worker (which has an architecture
> designed for asynchronous background processing) is the right vehicle for
> your "shared context" idea. My concern is that you're looking at the
> limited APIs currently available to web workers, and concluding that this
> makes them similar to shared contexts, when in reality the primary driver
> behind the limited worker APIs is thread safety, not UA privacy.
> 
> 
> >
> > The aim is not to work around JS being disabled, but to allow web pages to
> > be designed with document JS disabled that still support a lot of features
> > that are currently handled by the document JS.
> >
> > After giving it some more thought it would seem best to add new attributes
> > for communication with web workers so that the existing attributes could
> > implement a backup using a HTTP request - this might help support backwards
> > compatibility or allow content to degrade gracefully if web workers are not
> > supported.  For example, if a form is declared to be submitted to a web
> > work via a message post then it could also have a backup 'method' and
> > 'action' to make a HTTP request to a server.
> >
> > The best path for supporting DOM updates from received web worker messages
> > is not so clear to me.  Perhaps an iframe, or a more general element
> > extension that allows an innerHTML update to be received from web worker
> > messages and perhaps from server sent events.
> >
> > cheers
> > Fred
> >
> > > To: whatwg at whatwg.org; fredandw at live.com
> > ...
> > > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw at live.com>
> > wrote:
> > ...
> > > > 1. Declarative web worker creation.
> > > >
> > > > Feedback and suggestions for appropriate markup to declare web workers
> > > > would be appreciated.
> > > >
> > > > The use case is a document with JS disabled or restricted so that it
> > can  not
> > > > create web workers, yet still wants to create web workers to process
> > page
> > > > input and to update the document.
> > >
> > > Can you give some concrete examples where JS is disabled or restricted?
> > >
> > > --
> > > Simon Pieters
> > > Opera Software
> >
>