3 ms·

I imagine one of these DOM is "fake", i.e. it doesn't really have access to the UI. After all, the DOM is a generic API to work with structured node based docum

by aikah 8y ago

I imagine one of these DOM is "fake", i.e. it doesn't really have access to the UI. After all, the DOM is a generic API to work with structured node based documents. Changes to the DOM would still need to be serialized in order to be sent to the UI thread.

eridius 8y ago
Yes I know. Which is why I asked what happens if two Workers try to make incompatible changes at the same time. How does this library resolve conflicts when applying the changes from the fake DOM to the real one? In fact, this doesn't even require 2 Workers, you could get a conflict with a single Worker if you're also making DOM changes on the main thread.
- mygo 8y ago
  This is like asking what happens if two different micro-services try to make incompatible changes to the same database. Or what happens when two different users try to make incompatible changes to the same Google Doc? Or what happens when you try to GIT Merge a commit that has incompatible changes? It’s your code, so it’s in your control what happens, and also in your control how to react to what you can’t control. You can write code that avoids conflicting manipulations (let’s say all the dom manipulations only ever happen on one thread) or you can write code that handles the case... It’s a case by case kind of thing, there is no one answer.
  - eridius 8y ago
    All of these cases have a well-defined conflict resolution mechanism. All of these cases except for Google Docs explicitly have a way for the client to be notified that their requested change failed (I believe Google Docs just defines the editing operations such that a conflict can always be automatically resolved). The DOM API does not have any way to even notify the client that their DOM manipulation failed.
- MatthewPhillips 8y ago
  Without knowing the specifics of this project, more than likely they do not attempt to solve the problem you describe. Simply don't make changes to the real DOM, or use 2 workers on the same subset of actual DOM. Each worker owns its own DOM (most likely the entire page).

by aikah 8y ago

eridius 8y ago

Yes I know. Which is why I asked what happens if two Workers try to make incompatible changes at the same time. How does this library resolve conflicts when applying the changes from the fake DOM to the real one? In fact, this doesn't even require 2 Workers, you could get a conflict with a single Worker if you're also making DOM changes on the main thread.

mygo 8y ago
This is like asking what happens if two different micro-services try to make incompatible changes to the same database. Or what happens when two different users try to make incompatible changes to the same Google Doc? Or what happens when you try to GIT Merge a commit that has incompatible changes? It’s your code, so it’s in your control what happens, and also in your control how to react to what you can’t control. You can write code that avoids conflicting manipulations (let’s say all the dom manipulations only ever happen on one thread) or you can write code that handles the case... It’s a case by case kind of thing, there is no one answer.
- eridius 8y ago
  All of these cases have a well-defined conflict resolution mechanism. All of these cases except for Google Docs explicitly have a way for the client to be notified that their requested change failed (I believe Google Docs just defines the editing operations such that a conflict can always be automatically resolved). The DOM API does not have any way to even notify the client that their DOM manipulation failed.
MatthewPhillips 8y ago
Without knowing the specifics of this project, more than likely they do not attempt to solve the problem you describe. Simply don't make changes to the real DOM, or use 2 workers on the same subset of actual DOM. Each worker owns its own DOM (most likely the entire page).