- From: Lon Ingram <lawnsea@gmail.com>
- Date: Fri, 7 Sep 2012 10:53:14 -0500
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Andrea Marchesini <amarchesini@mozilla.com>, David Bruant <bruant.d@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
> On Thu, Sep 6, 2012 at 7:18 PM, Glenn Maynard <glenn@zewt.org> wrote: >> On Thu, Sep 6, 2012 at 12:31 AM, Jonas Sicking <jonas@sicking.cc> wrote: >> That is certainly an interesting use case. I think another interesting >> use case is being able to write synchronous APIs in workers whose >> implementation uses APIs that are only available on the main thread. > > > I understand the concept, but I'm having trouble coming up with useful > examples. Can you give one? I have one: virtualizing the API of the main thread in a worker. In Treehouse [1], we sandbox untrusted JS in a worker, where we provide a virtual browser interface - including the DOM (using a hacked up fork of jsdom). This allows us to (1) restrict the guest code to a subset of the DOM, and (2) interpose on privileged operations. At present, we present a synchronous interface to the virtual DOM and then replicate changes back to the actual DOM in the main thread asynchronously. This works surprisingly well, but has some limitations. First, concurrent access to a given DOM node from more than one worker is a difficult problem, so we punt and require that a node may appear in at most one virtual DOM. Second, we do not know how to virtualize some synchronous methods and properties, such as window.prompt. I believe that a synchronous messaging API would allow us to overcome both of these issues. [1] Treehouse PDF: https://www.usenix.org/system/files/conference/atc12/atc12-final159.pdf -- Lon Ingram @lawnsea
Received on Friday, 7 September 2012 15:53:42 UTC