- From: Andrew Wilson <atwilson@google.com>
- Date: Tue, 6 Nov 2012 08:05:57 +0100
- To: Fred Andrews <fredandw@live.com>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
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