- From: Anne van Kesteren <notifications@github.com>
- Date: Fri, 10 Nov 2017 12:15:59 +0000 (UTC)
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/270/343458762@github.com>
I looked into the concerns around `NodeToken` being an integer (or number). For the `DOMTreeConstruction` idea it can be an integer. The integers get returned as you use `DOMTreeConstruction`. The moment you turn those integers into nodes using `getNode()`, there's a reference to `DOMTreeConstruction` available and any lookup only happens within that object. An implementation could store a map of integers to nodes on `DOMTreeConstruction` the moment nodes are created as part of `insertTreeBefore()`. As these integers are therefore entirely self-contained, this even paves the path toward `DOMTreeConstruction` being serializable and network-transferable. To ensure we don't have to keep that map alive forever we could deterministically empty it by .then'ing the returned promise from `insertTreeBefore()`. Those details can be fiddled with, this just shows it's viable. `DOMChangeList` is trickier as the integers can also represent nodes in an existing tree (via `getToken()`, which is listed under `DOMTreeConstruction` in OP, but is not part of it as no method takes a `NodeToken` there), in a different thread. That means the integers for `DOMChangeList` need to be unique within an agent cluster and are probably not suitable for network-transfer, ever. It also means they need to be long-lived as they need to be able to transfer across threads. The fogeability problem I would address by when looking up the node corresponding to an integer, also ensuring that its node document is identical to the document upon which `applyChanges()` was invoked. And as said before for any instructions that are incorrect we'd abort, leaving you with a potentially broken tree as we cannot do transactions (see upthread). (Given the nature of integers in `DOMChangeList` I suspect there would need to be some requirement for them to be random to avoid fingerprinting.) So in conclusion I think both designs are viable. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/270#issuecomment-343458762
Received on Friday, 10 November 2017 12:16:23 UTC