W3C home > Mailing lists > Public > www-dom@w3.org > October to December 1998

Distributed DOM (was: Walking the DOM)

From: Claude Zervas <claude@utlco.com>
Date: Tue, 03 Nov 1998 21:00:16 -0800
Message-Id: <199811040507.AAA27698@www10.w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:46 GMT