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

[Tim Newman]

Which version of Ice does the controlport branch currently depend on?
I only ask because I think only Ubuntu 12.04 and 11.10 have Ice 3.4.2,
whereas older Ubuntu versions come with the Ice 3.3.x versions and
there are significant API changes between the two, so the "apt-get
install" may only be supported on 12.04 and 11.10.

Tim

On Mon, Nov 19, 2012 at 10:25 AM, Tom Rondeau <address@hidden> wrote:
> 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
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio