[Ace-users] [tao-users] Making use of TAO IDL compiler

[Jeff Parsons]

Hi, 

> -----Original Message-----
> From: J.T. Conklin [mailto:jtc at acorntoolworks.com] 
> Sent: Wednesday, November 21, 2007 10:03 AM
> To: Jeff Parsons
> Cc: tao-users at cse.wustl.edu
> Subject: Re: [tao-users] Making use of TAO IDL compiler
> 
> "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).
> 
> Hi Jeff,
> 
> 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.

Ah, I guess I wasn't entirely accurate ;-). You're right, tao_idl and
tao_ifr are different executables, but the same files are used to build
the driver part.

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

The two builds in TAO_ROOT/orbsvcs/IFR_Service are unrelated. One builds
the IFR Service executable (the meat of which is a linked lib whose
files
are in TAO_ROOT/orbsvcs/orbsvcs/IFRService) and the other builds the
backend lib of the IFR loader (and by 'loader', I mean the loading of
IDL definitions into a running IFR). While they both have to do with the
IFR of course, there is no compiling or linking relationship between
the two sets of files. In fact, they should probably be in separate
directories, to make the distinction more self-evident.

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

I had a hunch you might be thinking about a more runtime definition
of 'pluggable' and you're right, what we have with the IDL compiler
is purely a compile-time animal.

Jeff

> 
>     --jtc
> 
> -- 
> J.T. Conklin
>