The DOM and the victim, the iconoclast and the believer

[Didier PH Martin]

Hi,

After an hour of jogging (too bad, we do not have enough snow this week for
skate skiing), and a week struggling with the DOM I discovered something
interesting. He decided to interview my three fellow in this story: the
victim, the iconoclast and the believer.

The victim point of view:
Suppose that you developed an application based on the OMG IDL, to be more
precise a C++ application. So, when the DOM 1 recommendations where
published you wrote a DOM 1 set of interfaces in the OMG IDL format, used
the IDL compiler to translate the interface into C++ code, Got even the zeal
to compile a Java code version, let it cook in the oven for 5 minutes,
waited a couple hours until it is cool enough, implemented the code, and
finally got a DOM level 1 component. You where proud of your accomplishment.

Then, you started to make some experiment, plugged your DOM level 1
component with some DOM level 1 consumers, got surprised that it works, and
thought gee what a beautiful day...until DOM 2 came....

You then discovered something funny, they expended several interfaces with
new members. Bang W3C caused a mini version of the Y2K bug in your own
garden. You didn't got the time to fill your cellar with enough provision to
go through it. This is it! DOM 2 made it, the millennium catastrophe, you
where simply clueless on how briliant people can bring you so much
trouble....a courtesy of W3G (please maestro, can you play for the
circumstances "Also Spreach Zaratoustra" or maybe the Mozart Reqiem would
more appropriate - what are you recommending me :-).

Why did we ended there?

a) the C++ DOM level 1 client that you where using understood the DOM1
interface. the IDL compiler that you used translated the interface into a
virtual table. To make things simple a virtual table is a table of pointer
to functions. In C++, this virtual table is fixed and not expandable. Thus,
if you change the vTable, then the client will not be able to interface to
your component. Moreover, the new java client version that you just bought
do not work with your DOM level 1 component even if the manufacturer said
that it was compatible with your object broker (they said that they improved
it, made bug fixes, made it faster, you simply just could resist to get it)
b) Then to correct things, you simply write the DOM 2 interface as
recommended (even with a bit of zeal), compile it, let it cook...and bang
this time the is the other components that not work any more.  Because you
changed the vtable, itself the result of the IDL compilation, and because
nothing is said in the OMG specs on how to implement an interface, then,
using this freedom, the object broker manufacturer used a vtable, thinking
that it makes sense. But, the end result being that now you have an
impedance mismatch between two components, one that can only understand the
DOM1 interface and the other the DOM2 interface.

the iconoclast point of view now:
If W3C made its work properly, they would have first defined the DOM1
interface, and thought seriously about legacy maintenance, backward
compatibility, component robustness, etc... In simple words did a good
software engineering job.
What we would expect from the recommendations?
a) that a component implementing only the DOM 1 interface would be able to
work with a client that understand either the DOM1 or the DOM2 interface.
And vise versa. What this means? That the object would allow evolution and
backward compatibility by providing the possibility to query the interface.
For example, if the client can understand only a DOM1 node interface, then
it can query for a DOM1 node interface and do its work even if the provider
supports the DOM1 and DOM2 interfaces. I do not get it, he said, a bit
puzzled that W3C made such a big mistake. Ok let's recap

a) we define all interfaces as contracts something that is stable throughout
the time. A contract that can be fulfilled even if the components evolve. A
contract that can be fulfilled in spite of the component evolution. If we
change the contract we simply create a new one. If we change the interface,
we simply create a new one.
b) to do so, we have a mechanism to query the interface and get the right
one.

What? they say that your object broker should deal with that? Then how the
object broker can differentiate between two interfaces having the same name
but not the same specification? This is not mentionned in the OMG specs, so,
how can we expect that they would do it in a standard way?

What? they say, just recompile the code. but what do we do if we do not have
the source code?

What? they say, you're not suppose to have backward compatibility,
manufacturers should make some money and therefore you have to buy again all
the components each time a new recommendation is out. So, fine, please,
include this as a note to the recommendations please :-)

The believer point of view:
OK, the humans are born with good intentions, only the society corrupts them
(who said that? Jean Jacques Rousseau?). The WG didn't thought about
backward compatibility and good software engineering practices. But the next
recommendation will probably address these concerns. After all, these people
listen to our concerns. Or probably they got the following problem, they
wanted that the object to be called a node even if the interface evolves. If
we would have a backward compatibility process, then the interface would
have to be renamed and thus we would end up with an interface having the
name "node124" in the year 2020. Yes indeed this is a weakness of the OMG
model. But waht if we call the node "node_l1" or node_l2" OK "node_l124" is
not as esthetically appealing as simply "node" but at least, we know to whom
with interface and you know these days, it is preferable to know to whom you
interface :-). Seriously, they will address this concern, after all, I am a
believer.


And you, what are you? Have you given some thought about this issue. Is the
DOM a never ending prototype or a component definition with support for
backward compatibility and evolution (able to balance both). Also, did
someone experimented a DOM 1 or DOM 2 component compiled with a certain
manufacturer IDL and then tried to interface with a fully compliant OMG
component compiled with a different manufacturer IDL. Where you able to make
both work together? Especially in the same address space. Personally I was
able to do it if both where communicating on a socket using IIOP. Each one
running in a different address space.

Didier PH Martin
----------------------------------------------
Email: martind at netfolder.com
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.com


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/ or CD-ROM/ISBN 981-02-3594-1
Please note: New list subscriptions now closed in preparation for transfer to OASIS.