[Bug 26957] New: Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26957

            Bug ID: 26957
           Summary: Allow sending DOM objects to Workers and expose a DOM
                    (or DOM-like) interface to workers
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Workers (editor: Ian Hickson)
          Assignee: ian@hixie.ch
          Reporter: brunoaiss@gmail.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

I'd like to revive this bug and ask for a minor alternative that might be
possible and OK to go for.

The idea is to allow passing document fragments to worker threads (document
fragments only).

The main idea is that, sometimes, a large amount of changes or analysis are
required to be made to the DOM.

By allowing sending a fragment to a worker thread, the overhead required to
translate all the DOM send into an analyzable format.
You may even require
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode
Or some work adapting the content to the worker. As long as that is made in the
other thread, there's no issue on my end.


The main use case here is:
Extensive work is required to be made on a subtree of a page's DOM.
Here's an example generic use-case.

1. The main thread splits the DOM tree into parts and then it sends those parts
to the worker threads.
2. The worker threads do the DOM changes.
3. The worker threads send the changed DOM to the original thread.
4. The original thread integrates the changed DOM nodes from the workers into
it's own DOM.


The requirements for my use-case are:

 --- Worker having a nearly complete document DOM --- 
This document is not connected to any interface. In other words, it acts the
same way as a documentFragment towards everything (actually, it can even be an
actual documentFragment, if possible).
Any changes to it only changes that DOM tree inside the worker thread.

 --- You can pass DOM objects ---
A passed DOM object is read-only on the destination until
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode
(or equivalent) is called. This one may be harder to do because there's no
synchronization and implementing a copy-on-write may just be too much.
OR
Passing a DOM is made by cloning it to the document that resides in the worker
thread. The result of that clone is equivalent of passing it through the
importNode() method. This one should be the easiest to implement. It may be
slower, but then it should only affect performance for the first send
(considering that there are multiple workers).

There can be optimizations here such as for documentFragment. If transfering a
documentFragment it could behave just like a Transferable such as ArrayBuffer
(once transfered, it cannot be accessed from the source thread). As far as I
know, there's no way for a change in a documentFragment to be reflected in the
interface's document and vice-versa but there can be internal code requirements
that make this optimization impossible.


If this is enabled, when the parsing work on the js side is more complicated,
it may be sent to the worker thread to deal with the specifics and still have
tree-like operations with Nodes that look like the interface's DOM.


Just to keep it clear:
-> This is still not memory sharing, just memory transfer or memory ownership
transfer.
-> All changes inside the worker do not reflect on any other thread. I.E.
changes on a specific thread's DOM documents do not reflect on any other
thread's DOM documents.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Thursday, 2 October 2014 19:25:20 UTC