ICE vs. XPCOM for application development?

[yamokosk]

I am somewhat new to component-based programming, but have been using ICE through the ORCA library for a robotics control application.

We have started a new project which will be a single-computer application with a component interface for user contributed extensions. We are in the early design stages and currently trying to find the best library to handle the component interface. It must be open-source and cross platform, which narrows the choices to ICE and XPCOM (only ones I could find). XPCOM is "tailored toward providing modular component support at the application level". However, it appears as if using XPCOM outside of the Mozilla framework will be a royal pain (we are not developing a browser-based application). Then there is ICE which does not suffer from a browser heritage, yet its strength seems to be in distributed computing.

I have browsed the code snippets in the newsletters and it looks as if ICE would be fairly easy to embed in our application. But am I overlooking anything? Am I attacking this problem with sledgehammer or is ICE the better canidate vesus XPCOM.

[bernard]

Hi J.D.,

It's the first time I hear about XPCOM; from a quick look at the introduction, it looks like a fairly old, COM-like technlogy. If Ice is not suitable for your project, I suspect that .NET (the successor of COM/DCOM etc) would be a better choice than XPCOM.

Cheers,
Bernard

[michi]

First up, from your description, it certainly looks like Ice would be good choice for what you want to do. It's easy to use, and whether your components communicate among different machines, are in different processes on a single machine, or are in the same process makes no difference to Ice--the code is the same, and Ice figures out where each component is and how to reach it. It would definitely not be overkill for your situation.

Whether XPCOM would be a better choice than Ice is not so simple to answer--I'm not an XPCOM user, so I can only go by the information I can find on the Web (and, of course, seeing that I believe that Ice is the best thing since sliced bread, I'm naturally biased )

As you say, apparently, XPCOM isn't that easy to use outside the Apache framework. From what I read, it also only supports in-process components. While this may not be an issue for your application, with Ice, you can trivially (with zero effort, in fact) access components from another process.

XPCOM supports only C++ and JavaScript at the moment, whereas Ice supports C++, Java, Python PHP, C#, Visual Basic, and (soon) Ruby, giving you more options for development.

At the code level, I have to say I'm a bit underwhelmed by XPCOM's extensive use of macros. That sort of thing tends to cause trouble sooner or later and makes for ugly code. (Ice doesn't use any preprocessor trickery.)

Looking at the XPCOM pages, it appears that XPCOM isn't anywhere near as well documented as Ice. For example, I could not locate either a comprehensive XPIDL reference or a comprehensive C++ mapping reference. I would not underestimate the importance of having clear and understandable documentation for your project--comprehensive documentation can save hours of debugging time.

XPIDL is very similar to CORBA IDL, which suffers from numerous flaws. (See the end of the Slice chapter in the Ice doc for small sampling of those.) It appears that XPIDL simply toook what CORBA does without questioning whether what CORBA does actually makes sense.

It also doesn't bode well to find a caveat on the "XPIDL Best Practices" page that warns people about using out parameters for strings--incorrect use will lead to memory corruption or crashes. Ice doesn't have any such problems: the C++ mapping is completely safe, and it is literally impossible to accidentally corrupt or leak memory.

The XPCOM C++ language mapping also appears to be quite intrusive. For example, it defines its own string type. (Actually, it defines six different string types for different purposes.) That not only means that you have to learn a whole pile of things, it also means that XPCOM's strings cannot easily be interchanged with other APIs (such as the standard C++ library or pre-existing library code you might have written earlier). Ice simply uses std::string.

Similar comments apply to arrays. XPCOM defines several different C++ types to model arrays, whereas Ice simply uses std::<vector> (by default--you can also map sequences to a different collection type). XPCOM also defines five hashtable types, whereas Ice simply uses std::map.

From what could find on the XPCOM pages, it looks like Ice for C++ is *significantly* easier to program with than XPCOM, and doesn't suffer from flaws that can cause memory corruption.

I could go on like this for quite some time, I suspect. But, rather than me talking about something that I don't know too well, I'd suggest that you simply give Ice try. I suspect that if you do this, it will make Ice speak for itself.

Cheers,

Michi.

[yamokosk]

Wow, tremendous response michi. Thanks for looking into XPCOM and describing the differences. After I have learned more about ICE and XPCOM, I agree with much of your observations.

I believe I have seen some posts on this forum asking whether there any applications out there already using Ice, but they have not gotten many responses. It seems like Ice is fairly new to the scene, so I just want to make sure I am not crazy trying to use Ice for our purposes.

Again, I am a novice when it comes to component-based programming/design. But I just thought Ice would make the perfect foundation for a plugin based program.

[marc]

Ice is not so new anymore, and it is used in a lot of applications. For a small selection of commercial users, have a look at http://www.zeroc.com/customers.html. (This is not an exhaustive list--many customers didn't want to be listed.)

As for open source projects, there seem to be many smaller projects, university projects, research projects, as well as larger open source projects such as Orca. Scan through some of the posts here and follow the links in the signatures.