I just read about the release of
ControlPorthttp://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
Devin
On 11/18/2012 06:38 PM, devin kelly wrote:
I just read about the release of
ControlPorthttp://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
On Mon, Nov 19, 2012 at 10:05 AM, Philip B. [email protected]
wrote:
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
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:51 AM, Tim N. [email protected]
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
Tom,
Thanks for the detailed reply, I appreciate it.