RE: Node synchronization [was RE: Node identity comparisons on TS list]

>What I was saying that using "synchronized(node)" blocks is a de-facto
>method of accomplishing DOM synchronization externally, however that
>depends on an potentially unsafe assumption that accessing the same
>node returns the same object.

Implementation dependent. That will work in many existing Java DOMs. It
will also fail in some existing Java DOMs. (I'm currently in the process of
updating one where it fails.)

>It would seem that if you put any explanatory text on about isSameNode()
>then a warning about synchronizing on nodes would probably fit in there
>too.

Synchronizing on objects is a JAVAism, and probably shouldn't be mentioned
directly in the DOM spec, though it might be worth a note in the Java
bindings. However, isSameNode() will have to come with an explanation about
the difference between node identity and object identity, and a reasonably
clever Java programmer should be able to draw the proper conclusions.

>Maybe one way to enable (and only just enable) synchronization to be done
>would be to add a getUserObject() and setUserObject
>to Node

In addition to isSameNode, DOM Level 3 will introduce the concept of node
keys, which are symbols (probably integers)  that are uniquely associated
with specific nodes, and which can be used to implement this kind of "side
information" via an external table, possibly assisted by document mutatiion
events. (There are some serious disagreements about exactly what the
behavior of a fully-encapsulated "user object" hook should be as nodes are
cloned and so on. We decided the better part of valor was to provide just
enough to, permit folks to experiment with various alternatives and tell
_us_ what made sense.)



______________________________________
Joe Kesselman  / IBM Research

Received on Friday, 20 April 2001 18:29:35 UTC