Re: [Discuss-gnuradio] ZeroC ICE Choice for ControlPort

[Tom Rondeau]

On Mon, Nov 19, 2012 at 10:05 AM, Philip Balister <address@hidden> wrote:
> On 11/18/2012 06:38 PM, devin kelly wrote:
>>
>> I just read about the release of
>>
>> ControlPort<http://www.trondeau.com/home/2012/11/18/public-release-of-controlport.html>,
>>
>> (which I'm excited about) just wondering why use ZeroC ICE?
>>
>> Thanks for any explanation
>
>
> This is a start:
>
> http://www.zeroc.com/iceVsCorba.html
>
> Philip

Devin,

Yes, the comparisons between ICE and CORBA are definitely one reason.
We wanted the benefits of CORBA without all of its drawbacks, and ICE
is the logical choice. Also, it's easy to install and pretty easy to
learn how to use. It's available in most systems, like being able to
'apt-get install zeroc-ice' in Ubuntu and Debian.

Now, we could ask why we want something as complex as this for
ControlPort? ICE is pretty good at supporting other languages
(specifically for our needs both C++ and Python). We want it to be
robust, which takes a lot of thought and overhead. ICE has already
done that for us. One of the subtle but useful things that ICE does is
pass exceptions over the connection. So if one side throws an
exception (like say the running application crashes or is terminated),
the other side can gracefully shut down, free up resources, and exit.

It also provides mechanisms for authentication and encryption. We're
still working out details of how to make use of this, but it should be
pretty clear that this is something we want. For instance, we actually
have privilege levels for each variable that's exported. The intent is
that when connecting, the authentication mechanism would use your
credentials to determine what your privilege level is and only allow
you access to those parameters (for example, maybe you can 'get' all
the variables but you need special permission to be able to 'set'
them). Again, as these things are already designed into ICE, we don't
have to worry about how it's done; just how to use it.

But finally, I'll say this. If you look at the code, you'll see that a
lot of it is abstracted away from ICE. We've  tried to make it so that
we could replace it with other solutions if people want to or
something better comes along. You'll see some comments for XMLRPC and
Erlang in the code. We could also potentially use CORBA here, too, if
someone is crazy for CORBA. The main problem with this last bit is
that we haven't architected any other layers besides ICE, so it's
possible that a lot of our decisions are fundamentally rooted in ICE's
way of doing things. It's probably not unworkable, but I bring this up
because  it's likely that 'just' dropping in a new middleware might
not be 'just' that easy. Still, the intent is there.

Tom