RE: DCOM is now open code

["Didier PH Martin" <martind@xxxxxxxxxxxxx>]

HI Jeremy,
<YourComment>
Hmm.  The relevant page at Open Group,

  http://www.opengroup.org/comsource/

contains this definition of the DCOM package:

  While COMsource does not include the application programming interfaces
  (APIs) for object linking and embedding (OLE), or ActiveX? Controls, it
  does provide the underlying technology upon which they (or similar
  technologies) can be built.

I read this as telling us that we get a *drawing* of a box on four wheels,
based on which we can design a car...  It does absolutely *nothing* toward
making the real-world OLE and ActiveX apps freely interoperable across
platforms.  Somebody thinks we are all mushrooms...  <bg>
<YourComment>

<Reply>
More and more with this thread I feel like a guys in the middle age having
said something wrong against the wholly institutions and that the next step
is the inquisition :-)

Active X control are simply a marketing plug period. In fact active X
interfaces are DCOM interfaces. However script languages like Ecma script,
PERL or Python needs a IDispatch interface which basically is used for late
binding (same concept as CORBA late binding interface). The package includes
a IDispath marshaller and anyway, because it includes the MIDL you can
compile yourself a IDispatch interface with it. But the marshaller is
included. So it is technically feasible to implement late binding objects
that could work with script language.

But what this means is that any visual stuff is not part of the package.
Obviously DCOM has to be Windows independent and all helper function
provided to implement OLE which is essentially for visual objects or objects
that will interact with the user. So to be really windows independent, the
package should not contain any windows specific libraries dependencies.

With practical experience, I would say that the package is OK for non visual
objects or objects that not depend user interactivity. For example the
package could be used to implement a DOM or object like that. It could be
used also to implement an interpreter or parts of an interpreter. Anyway,
you understand the point anything that do depend on windows, button, menus,
etc... which are in fact platform specific. So the package cannot include
OLE stuff witch is windows dependent because it is about menu negotiation,
in place editing etc...

To tell you if you are or not a mushroom is not within my competencies :)

However, I can tell you that the package could be used for any "back end" or
"model" type of objects like for instance interpreters. That any objects not
using desktop libraries will work. Any object that need user interactivity
with the desktop library elements won't work because it is platform
dependant and the consortium choused not to include any dependencies with
Windows stuff. And, the writer made a mistake, you can implement a certain
class of active X objects as long as they do not have any user interface.
The package do includes the late binding marshaller named IDispatch to
implement such objects. The MIDL can also generate TypeLibs with could be
included in objects for late binding method discovery.

So, I cannot say if they provide you with a car without any wheel but I can
tell you that this is about the same kind of car that CORBA provides you. A
set of tool to implements services not visual objects or interactive
objects. But if you need fast services you can create a DCOM interface, map
it to a compiled language and compile it on different platforms without
having to rewrite your code. If you need cross-platform visual object this
is not the right tool. Java is better. Is you want to implement a service
and that maximum speed is not an issue, Java is better.
</Reply>

Regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list