On Mon, Nov 19, 2012 at 10:05 AM, Philip Balister <phi...@balister.org> 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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
