|Subject:||Re: [Discuss-gnuradio] ZeroC ICE Choice for ControlPort|
|Date:||Tue, 20 Nov 2012 11:23:17 -0500|
On Mon, Nov 19, 2012 at 10:51 AM, Tim Newman <address@hidden> wrote:Oh, that's a good point. Everything was developed against 3.4.2, so I
> 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.
expect there would be issues with the 3.3 release. The FindICE.cmake
file specifically checks for Ice-3.4, too, so older installations
won't even be tried.
> 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
>>>> (which I'm excited about) just wondering why use ZeroC ICE?
>>>> Thanks for any explanation
>>> This is a start:
>> 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.
>> Discuss-gnuradio mailing list
Discuss-gnuradio mailing list
|[Prev in Thread]||Current Thread||[Next in Thread]|