The DOM and the victim, the iconoclast and the believer

[Didier PH Martin]

Hi Ray,
Ray said:
1.  The CORBA IDL interface of DOM is not intended to be functional, but
rather only a
language-neutral way of expressing the interfaces.  It is not clear to me
whether a
functional CORBA binding is useful given that if the objects are
independently remote,
the efficiency problems may be too difficult, and if they are local, you
probably wanted
a more-local implementation.  CORBA has not done a great job of hosting
local objects.
IIOP is more robust than a local invocation.  The spec is silent on the
topic, so you
apparently cannot expect local objects to interoperate between ORBs.

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?

Ray said:
2.  Such an interwoven model as the DOM needs version covariance, which if
you are
limited to fixed interfaces produces extreme fragmentation and loses the
real type
identity of objects when you try to covary them in a graph, as is required
for DOM level
2, not to mention that invariant interfaces would force the simplest
navigation
operations in loops to involve typecasting for operations as every-day as
checking the
namespace.  Fixed interfaces work fine in large services, but not in
fine-grained object
models.  The DOM level is hierarchy-by-hierarchy, not node by node.
Discovering a level
1 node in the middle of a level 2 hierarchy would be catastrophic, yet
that's all the
navigation methods guarantee if you stick with fixed interfaces without
duplicating most
methods.  The so-called interface contract simply isn't adequate in this
type of setting
which requires covariance.  A node is still a node within a level 2
hierarchy, even with
a namespace attribute added.  A node would not be a node within a level 2
hierarchy with
no namespaceURI attribute, even though it was a node in a level 1 hierarchy
with no
namespaceURI attribute.  Intermixed success and failure of level 2 methods
within a
hierarchy would be intolerable in many cases.  You check the level before
you start to
perform operations, not by querying each node.


Didier reply:
Yes this is what I proposed in an other posting. To have an interface that a
client can query to obtain the right DOM version before requiring anything
else from the provider.

Ray said:
3.  Inflexible languages may wish to supply a seperate implementation for
distinct levels
to solve the covariance problem.  But a good number of bindings including
IIOP, Java,
Javascript, and so on can easily expand existing interfaces.  This turns out
to be a very
useful balance between splintering interfaces and objects without type.
Objects have
type, but the type is guaranteed as a complete hierarchy.  Level 1 and level
2 clients
can coexist with level 1 and 2 implementations in languages with enough
flexibility.  It
would be strange, for example, to force Javascript to query different
interfaces for core
features clearly part of the same object just because of other languages
that must do it
that way.

Didier reply:
What you mention here is late binding languages as found in most interpreted
languages. With these languages there is no big problems with interface
compatibility. But, as you know, the world is more diverse than than and
early binding language need a clear contract not a piece of soap. So for
early binding languages, you have to know the contract, you have to know the
interface and this latter has to be conformant to a certain specification.

Ray said:
4.  C++ by itself lacks enough mechanism to be binary-compatible with more
than one
version at a time.  Environments which expect reusability of binary objects
between
shared libraries define something beyond the standard C++ language to
prevent shifts in
the binary protocols.  Some fix the fundamental fragility of C++ vtables,
and some do
not.  Some allow the interfaces to grow, and some do not.  Raw C++ expects
no migration
of objects, so it is natural that a C++ binding would never expect to be
compatible with
more than one level at a time.

Didier reply:
Ray, for your information, there is some middleware interfacing models up
there such as XPCOM for instance that allows C++ languages or anything else
to provide a certain binary signature. This means that the different
components within the same address space have the same binary signature and
therefore can be binded properly. So, forget about using C++ binding which
obviously will not lead you anywhere. You need a binary signature
convention, so that objects in the same address space can communicate
together. Please, consult the very small doc available at Mozilla.org for
more info on this. And if you are incredulous about how a small bunch of
people did better on this facet than a whole consortium (i.e. OMG), then, I
can only say that talent is not necessarily proportional to the wallet size
:-)

Ray said:
5.  The common-yet-unstandardized CORBA approach of just handing C++
servants from a
separately-compiled library to a C++ client is the least-robust C++ model I
have seen.
Certain CORBA C++ implementations are more robust, such as SOM-based ones, I
believe.
The language bindings of the DOM are not auto-generated from the CORBA
IDL -- each
binding is permitted to do what is appropriate to the language to expand the
interface.
In COM, for example, an extension interface is added to an object to add
methods.  Since
C++ lacks any standard solution to the problem you will find a variety of
solutions
depending upon the hosting object model's binding capability, and how
flexible it is.  I
have raised the issue and called for robustness in the CORBA spec (in
addition to what is
already present in the IIOP spec).  But so many really are only using CORBA
for remote
objects, so it isn't clear if it is a useful pursuit.  It is not hard to do
in C++ if the
spec were to call for it, and it could be standardized so that local objects
would be
interoperable between ORBs.

Didier reply:
I agree that OMG never fully addressed the problem of inter-operability
within a single address space. You are right to mention that the actual
solution is not fulfilling this kind of need actually. In fact, the actual
OMG specs are well adapted for remote invication not for in-process usage.
Therefore, funny to see that a specification not well adapted to
intra-address space usage was used to define the DOM. Probably some
political presure within the DOM WG I presume.

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).

Cheers
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.