Tom, Thanks for the detailed reply, I appreciate it.
On Mon, Nov 19, 2012 at 11:02 AM, Tom Rondeau <t...@trondeau.com> wrote: > 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 > -- http://alum.wpi.edu/~dkelly/
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
