Distributed DOM implementations

[Eddie Sheffield]

Hello,

I've been considering the possibilities of such a system myself. One approach
might be to use intelligent stubs on the client side ("stubs" being the client
side objects that you interact with that in turn forward calls to the actual
server-side objects) that provide some caching and prefetching support. This
would require a lot more work, including probably hand-mangling the generated
classes, but could be a useful compromise. For example, when you first get a
reference to the root of the DOM tree, the stub goes ahead and fetches all the
root's attributes and direct childen. If you then refer to one of those child
nodes it's already available locally and so no server call is necessary. There
would need to be some kind of policy in place for dumping cached objects and
selecting which objects to cache to prevent the entire DOM from ultimately being
present in the client (might be a huge document and client resources might be
tight).

Any ideas? I'm tempted to take this notion to the CORBA lists as it's more a
distributed processing problem than XML.

Eddie Sheffield

"Ingargiola, Tito" wrote:

> Hi,
>
> Given that the DOM has an IDL mapping, writing distributed implementations
> of it should be easy.  Due to some of the choices made in that mapping,
> however, it's a little less clean than one might hope.  Specifically, the
> IDL and Java mappings are incompatible.  I had brought this up before in
> both this and the DOM mailing lists.  Stephen McConnell from the OSM
> (http://www.osm.net) was kind enough to explain why this was the case and
> what was being done to address it.
>
> In the meanwhile, out of curiosity, I wrote a set of adapters that provide a
> "bridge" between these inconsistencies in the Java & IDL mappings.  I've
> used these adapters to remotely manipulate DOM objects using the
> stripped-down CORBA implementation that comes with JDK1.2.  My experience is
> that you're not likely to be too pleased with the performance
> characteristics of such an effort, but it's pretty interesting to play with,
> and for some uses the performance characteristics may be acceptable.
>
> If anyone is interested, I'll be happy to send them a copy of these
> (extremely rough!) adapters.  Regards,
>
>         Tito.
>
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
> To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)