xml-dev - Re: The DOM and the victim, the iconoclast and the believer

[Ray Whitmer <ray@xmission.com>]

Didier PH Martin wrote:

> Didier reply:
> Why then also include exceptions? If this where simply a template then why
> having so much detail. So much details that the interface can be compiled
> and mapped to a particular language. This is more than a template. This is a
> fuly fonctional OMG IDL. If the intent was to provide just a template, then
> it is easy to write an abstract interface without having to use OMG IDL no?
> And yes, you are right the OMG spec do not mention anything about in process
> usage. Only inter-operability between object through sockets and IIOP is
> properly defined. Then, why use an interface definition that is not adapted
> to in-process processing? Most of DOM processing will happen in process no?
> Then why use an interface definition with a specification specialized for
> remote invocation?

Most languages include exceptions.  I would not advocate using any language as
a template for others to follow without following the letter of the language as

much as possible.  The only thing not addressed in the CORBA binding was
how to evolve a fragile C++ vtable from one version to the next, where there
is not even binary a standard that relates that vtable to CORBA.  The IIOP
interoperability works fine just as it has been defined if you ignore
performance.

While OMG defines IDL for use in remote processes, IDL doesn't seem to
be biased against definitions for local object systems.  Whether a particular
object system is robust enough to preserve binary compatibility in a
covarying object model is a different question, but each language binding
is free to pursue the most natural course for that language.  For some fragile
bindings, it is probably best to declare incompatibility between levels 1 and
2.  Others may provide a solution that can be binary compatible with both
versions.

> Ray said:
> I am working on my own C++ binding for DOM right now that has none of the
> traditional C++
> fragility problems, again, by introducing a more-robust object model, which
> I call CROS
> (C++ Runtime Object Standard)...
>
> Didier reply:
> OK Ray, in fact, you are proposing a new middleware. Its OK. So now the
> question is: is your spec resolving the problem of intr-address space usage?
> can I develop a component in, let's say, Python and have it used by an other
> one developed in  C++? If yes, you probably defined a binary signature and
> if this is the case, please let us know what is your solution. This may be
> interesting to learn and probably to use if you provide tool to make it a
> reality. Since then, XPCOM is freely available. Or when the WINE project
> will have made some progress, their DCOM implementation may be interesting
> (but actually lack an IDL compiler).

I agree about talent not being related to wallet size.

I dislike the COM approach for fine-grained object models.  Therefore I am
indeed proposing new middleware, but you should give my effort a few months
to release a functional DOM and other examples.  I have spent many years
researching, designing, and prototyping this type of middleware, and the larger

XML-based office suites that it makes possible, built on arbitrary content
models with completely configurable fine-grained independently-supplied
components to match.

But I only decided 12 days ago to start building a suitable object model for
these
purposes so that I could do this work on the side, after, again, spending years

investing in Java, only to be repeatedly disappointed with Sun's unwillingness
to
open up the model so we can solve some fundamental problems there and
leverage other great non-Java work in the process.  Hence:

http://www.xmission.com/~ray/CROS.html

You probably shouldn't be interested in the project at this early stage.
Whether
it will ever reach any degree of acceptance or credibility is far from known.
The
only reason for you to look at it at this point would be to provide feedback,
or tell
me that you think the solution is already available somewhere else.  I am still

mostly modelling designs rather than coding.  The tool will come in a month or
so.

To answer your question, it does solve the problem of binary compatibility when

reusing or inheriting code between separately-compiled shared libraries which
may
have quite different versions of an interface.  I think it will compliment a
CORBA
ORB for inprocess access quite nicely in this respect.

It is based upon a core dispatch lookup, which populates dispatch tables.  The
dispatch table is never stored in the object, but rather as a second field in
the
object reference, with efficient techniques for caching dispatch tables so they

only need to be built once for a particular shared library and so that most
operations that are simple with minimal fixed overhead in C++ remain simple
with minimal fixed overhead.  Dynamic generic classes are easily obtained.

Ray Whitmer
ray@xmission.com



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.