On Mon, Nov 19, 2012 at 10:51 AM, Tim Newman <tim.new...@gmail.com> wrote: > 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
Oh, that's a good point. Everything was developed against 3.4.2, so I 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. Tom > On Mon, Nov 19, 2012 at 10:25 AM, Tom Rondeau <t...@trondeau.com> wrote: >> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
