Re: [whatwg] Declarative web worker creation and communication?

On Tue, Nov 6, 2012 at 2:21 AM, Fred Andrews <fredandw@live.com> wrote:

> 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.
>

I'd encourage you to look at the MessagePort APIs, if you have not already.
Agreed that using messages to pass data between different contexts is a
powerful mechanism.


>
> 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?
>

The Document is not made available - really, this section is just
describing when it's safe to shutdown a worker (which can be quite complex
when you have workers that create other workers, and shared workers).


>
>
> "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?
>
> I don't think the plan is to allow navigation of the browsing context -
I've always understood this section to mean that the worker shares a
browsing context with the creating document for the purposes of cross-site
XHR access, cookies, etc. I'm not at all sure what "set the script's
document" means, but I'm not particularly fluent in spec-speak - I'm sure
someone else on the list can explain the ramifications of that.


>
> "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?
>

There have been discussions about some aspects of this (you can check the
list archives - some people have wanted to be able to pass portions of the
DOM back and forth to workers) but fundamentally the DOM provides a
non-thread-safe API so I don't see how this would ever be possible.


>
> 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?
>

I know there has been discussion about more efficient ways to pass/share
data between documents and workers - this would enable things like
background rendering to canvas, etc. Some of the discussion has happened on
the W3C lists (such as
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0744.html) so
I'd suggest looking at those archives also.


>
> cheers
> Fred
>
>
> > Date: Mon, 5 Nov 2012 10:41:00 +0100
> > From: atwilson@google.com
> > To: fredandw@live.com
> > CC: whatwg@whatwg.org; simonp@opera.com
>
> > Subject: Re: [whatwg] Declarative web worker creation and communication?
> >
> > On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews <fredandw@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@whatwg.org; fredandw@live.com
> > > ...
> > > > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw@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
> > >
> >
>

Received on Tuesday, 6 November 2012 07:06:30 UTC