Lists Home |
Date Index |
- From: "Didier PH Martin" <firstname.lastname@example.org>
- To: "Ray Whitmer" <email@example.com>
- Date: Sat, 15 Jan 2000 22:02:00 -0500
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
functional CORBA binding is useful given that if the objects are
the efficiency problems may be too difficult, and if they are local, you
a more-local implementation. CORBA has not done a great job of hosting
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.
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
2. Such an interwoven model as the DOM needs version covariance, which if
limited to fixed interfaces produces extreme fragmentation and loses the
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
operations in loops to involve typecasting for operations as every-day as
namespace. Fixed interfaces work fine in large services, but not in
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
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
no namespaceURI attribute, even though it was a node in a level 1 hierarchy
namespaceURI attribute. Intermixed success and failure of level 2 methods
hierarchy would be intolerable in many cases. You check the level before
you start to
perform operations, not by querying each node.
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.
3. Inflexible languages may wish to supply a seperate implementation for
to solve the covariance problem. But a good number of bindings including
to be a very
useful balance between splintering interfaces and objects without type.
type, but the type is guaranteed as a complete hierarchy. Level 1 and level
can coexist with level 1 and 2 implementations in languages with enough
interfaces for core
features clearly part of the same object just because of other languages
that must do it
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.
4. C++ by itself lacks enough mechanism to be binary-compatible with more
version at a time. Environments which expect reusability of binary objects
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
of objects, so it is natural that a C++ binding would never expect to be
more than one level at a time.
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
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
Certain CORBA C++ implementations are more robust, such as SOM-based ones, I
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
In COM, for example, an extension interface is added to an object to add
C++ lacks any standard solution to the problem you will find a variety of
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
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
interoperable between ORBs.
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.
I am working on my own C++ binding for DOM right now that has none of the
fragility problems, again, by introducing a more-robust object model, which
I call CROS
(C++ Runtime Object Standard)...
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).
Didier PH Martin
Conferences: Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
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.