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

[J.T. Conklin]

"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