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

Jeff Parsons j.parsons at vanderbilt.edu
Wed Nov 21 08:32:18 CST 2007


Hi,

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

thanks,

Jeff

> -----Original Message-----
> From: tao-users-bounces at cse.wustl.edu 
> [mailto:tao-users-bounces at cse.wustl.edu] On Behalf Of J.T. Conklin
> Sent: Wednesday, November 21, 2007 8:19 AM
> To: Vikram Karandikar
> Cc: tao-users at cse.wustl.edu
> Subject: Re: [tao-users] Making use of TAO IDL compiler
> 
> "Vikram Karandikar" <softking at gmail.com> writes:
> Hi Vikram,
> 
> > Now a normal compilation of this IDL file with TAO idl compiler will
> > generate the stubs and skels. I want that too, but in addition to
> > that i also want to generate constructors for all the structs. I
> > know if i modify the IDL compiler code then i can achieve this.
> >
> > Is there any TAO IDL development document available? Any 
> guidelines? 
> > Any suggestions?
> 
> I think you'll find the code is all the documentation there is.
> 
> That being said, going this route will likely lock your system to TAO
> plus your local tao_idl compiler modifications. This is not something
> I would do myself unless there were no other options. Even though I
> have no plans to use any other ORB, knowing that those other ORBs
> exist is a big factor why I chose CORBA as my middleware layer.  It
> wouldn't necessarily be painless, but I could migrate to any other
> ORB.  A local modification like the one you suggest could essentially
> be self-imposed vendor lock in.
> 
> If I needed custom constructors for structs, I'd most likely change my
> *.idl to use valuetypes instead.
> 
> FWIW, when I marked your message yesterday as something I wanted to
> respond to, I thought you were asking whether TAO's IDL compiler
> supported pluggable/strategized back ends. Some other ORB's have this,
> so you can write your own plug-in to easily generate code derived from
> your IDL.  For example, in my system there is a server that bridges/
> routes requests. All the servant methods simply forward the request to
> the "real" object with something like:
> 
>    CORBA::ULong
>    FooProxy::do_something(const char *s, CORBA::ULong x)
>    {
>      return impl_->do_something(s, x); 
>    }
> 
> As you can see, something that could be easily generated from IDL.
> 
> Deep down on my queue is to see if I could use OmniORB's IDL compiler,
> which does support pluggable back ends, to replace my hand written
> proxy servants with generated implementations. The problem is that the
> proxy servants only take a few minutes to write, so when I need to add
> just one more, it is a lot less effort to just do it than to figure
> out how to do a new back end.  Adding a pluggable back end support to
> TAO's IDL compiler, however desirable it might be, isn't even on the
> table.
> 
> Sorry for the tangent.  Before I go I'll say again to strongly
> consider what you're planning to do.  Vendor lock in, even to a open
> source product like TAO, has its costs.
> 
>     --jtc
> 
> -- 
> J.T. Conklin
> 
> _______________________________________________
> tao-users mailing list
> tao-users at mail.cse.wustl.edu
> http://mail.cse.wustl.edu/mailman/listinfo/tao-users
> 



More information about the Ace-users mailing list