- From: Claude Zervas <claude@utlco.com>
- Date: Tue, 03 Nov 1998 21:00:16 -0800
- To: www-dom@w3.org
At 06:59 PM 11/3/98 -0800, you wrote: > <snip/> > Such an iterator can be used, for example, to traverse >documents that are never entirely present in memory, or exist on a remote >server. Sounds good. This brings up another point I have made in the past that seemed to draw a lot of fire which was the idea of implementation-independance at the interface level. In other words, allowing mixed implementations. This is fairly useful if part of a tree resides on a remote machine and it is not possible to guarantee that the remote DOM implementation is the same as the local one. For example, if I have an HTML document tree where some of the child nodes are remote references , it would be nice not to have to copy all the remote nodes locally in order to traverse/mutate them. Especially if you want to automatically see changes made to the document on the remote tree fragment. Also, some actions can be much more efficient if the nodes do not need to be copied over the wire. For example, if you call Element.getElementsByTagName() on a remote element then it is obviously better if this executes on the remote machine instead of copying the element and its (possibly huge) subtree locally. Fully distributed DOM documents are very useful in collaborative environments and it is important the platforms do not have to be homogeneous (in the DOM implementation sense). What if a remote site gets an upgrade or changes DOM vendors? People have suggested using EntityReferences or XPointers to do this, but neither are as natural or straightforward as simply distributing the nodes themselves. I do not think they can solve the problem of heterogeneous implementations either. With a DOM spec that is performance-friendly it should be not only be possible but relatively straightforward to create an implementation that makes no assumptions besides the defined public interfaces and that is fairly efficient as well. Perhaps this could be another optional feature... And for further thought, how about "VisitorAgents" that can hop remote reference boundaries and propagate down a remote tree? Regards, Claude Zervas
Received on Wednesday, 4 November 1998 00:07:27 UTC