[Ace-users] [tao-users] Making use of TAO IDL compiler
jtc at acorntoolworks.com
Wed Nov 21 10:02:50 CST 2007
"Jeff Parsons" <j.parsons at vanderbilt.edu> writes:
> Maybe I'm misunderstanding what you mean by 'pluggable
> back end support' for the TAO IDL compiler, but there
> are already several backend generator libraries used
> with the same frontend parser library and driver executable.
> In the TAO distribution, please see
> TAO_ROOT/orbsvcs/IFR_Service where, in addition to the IFR
> Service executable, there are files to build an IFR loader
> backend for the IDL compiler. In the CIAO distribution,
> there is a backend in CIAO_ROOT/tools/IDL3_to_IDL2 that
> converts IDL containing component and home declarations
> into the equivalent 'implied IDL'. Other backends can
> be found in the CoSMIC toolsuite distribution that convert
> IDL into PICML, our component system modeling language,
> and WSDL (Web Services Definition Language).
While I was aware that the IDL compiler and IFR used the same front
end with different back end libraries, I wasn't aware that there were
so many other back ends. Also I'm looking at the current sources, and
I'm not seeing the use of the tao_idl driver executable; it appears
tao_ifr links the driver, front end, and back end libraries together.
And the TAO_IFR_Loader appears to be service config object (to be used
with TAO_Service, etc.), which is the dynamically loaded equivalent of
the IFR_Service server. To the best I can tell, it doesn't act on IDL
(The IFR_Server library isn't linked with any of the TAO_IDL libraries).
However, the multiple back ends suggests that TAO's IDL compiler may
be much farther along towards what I was meaning by "pluggins".
It's my understanding that the OmniORB IDL compiler you can specify a
back end on the command line, and that back end will be used when
compiling the IDL. The OmniORB back ends are written in python, which
makes things a bit easier. I vaguely recall reading docs for one of
the commercial ORBs (Orbix?) that had a similar capability where the
plugins were writtin in something like tcl.
For TAO, I was imagining the backend interface being a dynamically
loaded library loaded by the driver. A somewhat higher barrier to
entry than python or tcl, but still very usable.
More information about the Ace-users