From kragen@dnaco.net Fri Jul 31 22:26:58 1998 Date: Fri, 31 Jul 1998 22:26:56 -0400 (EDT) From: Kragen To: Eric Blinn cc: clug-user@clug.org Subject: Re: CORBA on Linux (was Re: KDE respone) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Keywords: X-UID: 935 Status: O X-Status: On Fri, 31 Jul 1998, Eric Blinn wrote: > On Fri, 31 Jul 1998, Kragen wrote: > > On Thu, 30 Jul 1998, Jim Weirich wrote: > > > > > Could CORBA be used as the glue between a (say...) C++ Window toolkit > > > and a non-C++ application? > > > > Yes. > > However, I would imagine you could write a > CORBA server that is essentially a bunch of wrappers for the toolkit. The > server would present the widgets and handle the input events. You could > then write a client in whatever language you wanted as long as it had the > necessary CORBA support. Your application would actually be two separate > processes, a GUI server and an functionality client. Is this along the > lines of what you are thinking Kragen? Yes. > > > What kind of constraints are placed on you by the CORBA paradigm? > > > > No real-time guarantees for anything. IIRC, no object mobility. > > The things Kragen mentons would be accurate constraints of CORBA in > general. There is also the fact that CORBA is a weak standard, as opposed > to ANSI C being an example of a strong standard. ANSI C code should > compile unchanged with any ANSI C compiler. This is not true of the CORBA > standard. If I develop a client using the IONA Orbix CORBA implementation > it won't necessarily (in fact almost certainly) compile unchanged to use > the MICO CORBA implementation. ANSI C is a language standard, and as such, its goal is to have programs that can compile unchanged. CORBA is an interface standard, and as such, its goal is to have programs that can interoperate. The analogous test for CORBA is not whether you can write a program using one ORB and then relink it with another; after all, you might have written your program in C++, while the other ORB works with Java programs. The analogous test for CORBA is whether programs using Orbix can talk to programs using MICO, using IIOP. At the moment, I think the answer is "almost". :) So you're right that it's a bit of a weak standard. By the way, I'm far from a CORBA expert -- I haven't even read the specification. I would greatly appreciate CORBA experts descending from the clouds and correcting me :) > . . . This isn't to say that CORBA objects > using different ORBs can't interoperate, they just aren't necessarily > source code compatible. That is the key -- that CORBA objects using different ORBs interoperate. > [1] ORB - The Object Request Broker is a CORBA implementation. Orbix, > MICO, and ORBit are examples of ORBs. I think Orbix is the most popular proprietary ORB right now, isn't it? ILU is one of the oldest ORBs, predating CORBA. Kragen