Manuel M. T. Chakravarty writes:
>
[snip]
>
> Although, you continue with
>
> Ideally, it should be possible to substitute COM for any
> other component technology. Experience may prove
> otherwise, but implementing an interface to one component
> technology is a non-trivial amount of work, so, as a
> starting point, we're targetting COM.
>
> For me that reads like it works for COM and you do not
> exclude that it is possible to rewrite it for another
> component technology.
>
It doesn't mean anything more than it says: we will provide a binding
to COM first, before going on to other component technologies,
resources being finite and all that. And since the range of types
supported by OSF DCE IDL (which the Microsoft IDL Compiler uses to
describe COM interfaces) and OMG's CORBA IDL are largely compatible,
it will not constitute a rewrite of the compiler.
How this can be construed to mean that this effort is founded on
proprietary standards (hence being 'useless'), I do not understand.
>
> A prerequisite for interfacing to a software component is
> some mechanism for communicating what functionality the
> component offers. H/Direct makes use of an Interface
> Definition Language(IDL) to specify component interfaces,
> and provides an IDL compiler that supports both the creation
> and use of software components.
>
> There's a couple of IDL flavours around. We're
> implementing one that is compatible with the IDL
> accepted by the Microsoft IDL compiler (MIDL), a
> superset of the IDL defined by OSF's DCE spec.
>
> So, it seems that it works for MIDL and COM, which are
> definitely proprietary, and you seem yourself unsure about
> how far it is from other standards.
>
If you want to align yourself with some component technology, such as
COM, you'll better talk their common interface language, no? The IDL
that Microsoft supports is OSF DCE IDL (developed for specifying
RPC-based interfaces), but extended with a couple of new declarations
to support describing software component interfaces (i.e., the
extensions are there out of *necessity*.) Microsoft's use of IDL
preceeded the availability of something like CORBA's IDL, which is one
reason why COM interfaces aren't specified using CORBA syntax.
But, frankly, the language doesn't matter - if NoddyBasic had been used,
that's what we would have to support too! If Microsoft should decide
to change their IDL, our compiler would have to change too, same as if
OMG should publish an IIOP-3 spec that made a number of changes to
their IDL.
> Maybe I just completely misunderstood the cited paragraphs;
> in this case, I would happily receive any clarifying
> explanation. Your recent posting seems to be to that
> effect. You wrote,
>
> > The IDL compiler uses an FFI substrate that allow Haskell
> > to call external functions with a C calling interface (or a variation
> > thereof), and vice versa, Haskell functions (or closures) can be
> > dressed up with a C calling interface. On top of that, we've currently
> > got a compiler grokking OSF DCE IDL (which, by my reckoning, is not
> > proprietary) extended with a couple of MS ODL declarations to allow
> > certain kinds of COM idioms to be specified conveniently. This gives
> > us access to COM, which I think is a step in the right direction.
> >
> > A different front-end would be to support CORBA on top of the FFI (see
> > followup I posted yesterday about this) - it's no big deal.
>
> If it is really just ``a couple of MS ODL declarations'',
> which are easily replaced with something non-proprietary,
> the situation would indeed be quite different from what I
> understood from the `H/Direct' document. It might be
Somehow providing your own custom interface language doesn't have much
merit here in my opinion, see above (and the experiences made with
Green Card.)
--Sigbjorn
