[boost] [RFC] Modern CORBA C++ IDL Mapping and implementation

Subject: [boost] [RFC] Modern CORBA C++ IDL Mapping and implementation
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2014-05-10 21:20:06

Hello Boosters,

Where I work we are implementing an open source, modern, CORBA
implementation and IDL mapping.

We want it to support C++ and C++11 IDL mapping, but we also want to
create another IDL mapping.

This new IDL mapping is being experimentated in the following url
https://github.com/expertisesolutions/mORBid/tree/concepts

It still has some very problematic issues (like compilation-time of
generated code) and of course it is still far from completion. But, we
would like to hear suggestions about this approach.

What we did was that an IDL interface is mapped to a typedef for
boost::type_erasure (I found the idea quite cool for the reasons that
I'll mention below) with the requirements defined in the IDL, e.g. its
operations.

The IDL also emits a model for this type_erasure which is the actual
stub class and is called remote_reference. It also emits a
proxy_reference model for the same type_erasure typedef which receives
a std::reference_wrapper and proxies the calls, this is needed because
type_erasure can't switch between by-reference and by-value in
runtime.

Why I believe this approach is better than current IDL to C++11
mapping: Because the IDL to C++11 mapping is too intrusive. You can't
really use normal classes you have written for use as servants in
CORBA because you have to inherit from Skeletons classes *and* you
have to use the *exact* same signature as defined in the mapping. This
is *way too restricted*. This is also inerent to the OO paradigm that
CORBA uses.

But, we can mimic the same features using type-erasure instead of
directly using dynamic polymorphism. This gives a much greater freedom
to users. It might be that Boost.type_erasure is not the best tool
here because of compile-time and compiler memory usage, but the idea
surely is. We still haven't seriously profiled boost.type_erasure yet,
but we will do so as soon as possible.

I think it might be very interesting to experiment with lite concepts
and Boost.concept_check as well.

Also, we created a EDSL for GIOP and IIOP mapping based on the
boost.spirit infrastructure. We use that to treat alignment and
endianness automatically and to use the same grammar for generation
and parsing of IIOP messages. The message header grammar is defined
like this:

    start =
      "GIOP"
      & octet('\1')                  /* GIOP major version */
      & octet('\0')                  /* GIOP minor version */
      & endianness
      [
       octet(MessageType)            /* message_type */
       & raw_size(ulong_)[body]
      ]
      ;

Which is compiled to IIOP parser or generator through boost.spirit
infrastructure of make_terminal, make_directive and etc. This works
splendid well and is really easy to use, extend, is statically checked
and has great performance.

Whoever feel interested, please take a look and comments are highly appreciated.

Regards,
-- 
Felipe Magno de Almeida