Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
CORBA and Open Source

By Carnage4Life in Technology
Sat Sep 30, 2000 at 02:41:39 PM EST
Tags: Software (all tags)
Software

Being a distributed computing junkie and a strong believer in Open Source software and Linux in particular I have been often surprised by the disdain that Open Source hackers have for using component technologies and distributed computing. When Miguel De Icaza correctly pointed out that *nix is long overdue for a unified component architure similar to what has been available for Windows for almost the past decade, he was met with derision by most people who responded to the story on Slashdot.


ADVERTISEMENT
Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
ADVERTISEMENT
Interestingly, when I posted my experiences with component technologies on Windows to that thread it was favorably received which made me wonder if people actually realized what comprised distributed object/component technologies. For this reason I thought it would be useful to provide some of the readers of K5 with a paper a friend and I wrote on distributed technologies which briefly explains CORBA, DCOM, and Java-RMI with code examples. Here's the paper. The paper references material from both the Java Tutorial site as well as the CORBA website. I wrote the parts on CORBA and RMI while my friend wrote the DCOM section.

The rest of my comments are directed at developers who contrary to popular belief use CORBA to build successful, large-scale, distributed applications. Here's my question:Why do you think CORBA is not used more in Open Source software? I have tried to come up with reasons for the lack of enthusiasm amongst Open Source developers for CORBA, and have come up with the following answers:
    CORBA is hard.Due to the fact that the CORBA specification does not require ORBs to provide services that are integral to most distributed applications such as transactional support, security, a naming service, event handling, and object persistentce, the onus is often on the developer to provide these services for his or her application. As the KDE developers recently found out, being talented at hacking C is not enough to prepare one for the myriad complexities that encompass distributed computing. Fortunately with the advent of GNOME's Bonobo and the Corba Component Model, perhaps this will become a thing of the past.
    Components lead to too many interdependencies. Some people point to DLL hell on Windows machines as well as the growing amount of interdependencies amongst GNOME libraries as a reason to be wary of using components. Both GNOME and Microsoft have made strives in designing their component architectures and versioning systems to avoid the mistakes of yester-year. Of course, this does not mean that multiple interrelationships do not exist between software components but instead that with proper design a lot of problems related to interdependencies can be solved. Admittedly more than a few people have mentioned that the interdependencies in the GNOME libraries are rather excessive.
    CORBA is a buzzword just like XML. This mentality is the most difficult to understand but is rather common in the Open Source world. All I can say to counter this is that although some technologies may have been hyped it doesn't change the fact they are useful. This includes Java, CORBA and XML.
    Distributed Computing not Taught in Schools. Even though a majority of college programs teach C and operating system internals, the same cannot be said for distributed computing. This may explain why there are many people hacking away at the Linux kernel and writing various Linux applications using C but very few are writing any applications that use CORBA.
    No Open Source CORBA Orbs. A lot of people are under the impression that all ORBs are proprietary and expensive but this is far from the truth and in fact there are several Open Source CORBA ORBs including TAO, MICO, Jonathan,JacORB,and ORBacus
Are my reasons correct and does anyone think anything can be done to reverse the current trend in Open Source software to shy away from CORBA and other distributed/compnent technologies?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
What distributed object/component technologies do you use when writing software?
o DCOM/COM+ 3%
o Java RMI/EJB 20%
o CORBA/CCM 16%
o I don't use this distributed objects crap. 43%
o I don't write software. 16%

Votes: 60
Results | Other Polls

Related Links
o Slashdot
o *nix is long overdue for a unified component architure
o my experiences with component technologies
o paper
o Java Tutorial site
o CORBA website
o contrary to popular belief
o KDE developers recently found out
o GNOME's Bonobo
o Corba Component Model
o DLL hell
o Java
o CORBA
o XML
o TAO
o MICO
o Jonathan
o JacORB
o ORBacus
o Also by Carnage4Life


Display: Sort:
CORBA and Open Source | 34 comments (34 topical, editorial, 0 hidden)
Why I don't use distributed component models (4.00 / 12) (#1)
by fluffy grue on Sat Sep 30, 2000 at 12:50:59 PM EST

It's not that I think they're crap - I don't. In fact, I love distributed component models. They're a Good Thing.

However, I haven't yet written anything which needs distributed component models. Simple as that. :)

IMO, for stuff which isn't intended to be run on multiple CPUs (i.e. most of the software out there), the only component model you need is the shared dynamic library model already existing in all modern OSes. OpenGL is already a component, Xlib is already a component (and it can easily be argued that Xlib is a decent, if not pretty, distributed component model as well - and you CAN pass arbitrary data through it, using atoms)... as far as distributed file access goes, well, NFS and Coda seem to do their job just fine (in a secure way, when set up correctly).

That said, database servers could probably benefit from CORBA or the like. Like, I'm surprised mySQL or Postgres don't use Gnorba (Gnome's GPLed ORB, which I'm surprised you didn't mention, especially considering that the CORBA standards people have adopted Gnorba as a standard implementation from what I've heard) in order to do their respective clusterings. Myself, I'll probably use either CORBA or MPI for the clustering of my database server for my 3D engine. (I'm not sure whether I'd rather have the overhead but relative simplicity of CORBA or the roll-your-own of MPI. CORBA would probably be better for the kinds of things I'm doing though, especially since if a node goes down in a CORBA cloud another node could conceivably take over, whereas in MPI if one node goes down, the whole cluster dies.)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]

Re: Why I don't use distributed component models (3.00 / 11) (#5)
by fluffy grue on Sat Sep 30, 2000 at 01:56:25 PM EST

Oops, I was getting gnorba (the Gnome CORBA services) confused with orbit (the Gnome ORB). Still, I'm surprised you didn't mention orbit, as someone else pointed out. :)
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

OT - thoughts on moderation (3.75 / 4) (#18)
by PresJPolk on Sat Sep 30, 2000 at 07:49:03 PM EST

Comment #5 (the comment I'm replying to) is a perfect example of why overloading the significance of commentmoderation could be a bad idea.

A brief comment, making a fairly minor correction, isn't worthy of a 5, on its own merits. If I'm sorting comments based on how interesting they are, I'd want this one at the bottom. In that light, a 1-2 is a reasonable score.

However, a rating of 2 on a comment impacts more than sort order. It influences the author's good standing in the community. Is comment #5 a sign that fluffy grue shouldn't be trusted? He's clarifying his statement. Confusing facts is often interpreted as ignorance of a subject, and lends itself to attacks on credibility. If fluffy grue and others can't clarify themselves without jeopardizing their trusted status, that's just silly.

[ Parent ]
Re: OT - thoughts on moderation (3.00 / 2) (#20)
by fluffy grue on Sat Sep 30, 2000 at 11:25:11 PM EST

Yeah, personally I'd have preferred that everyone had just left it at 'none.' You don't HAVE to moderate *everything*...

I mostly ignore the rating system in any case. The only difference my "mojo" makes to me is whether or not I can make a 0 rating, and that's so rare that I never do. I occasionally rate other comments which strike me as particularly insightful or whatever, but for the most part the moderation system could just disappear and I wouldn't notice any real difference (except that Netscape won't render the page so slowly).
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Re: Why I don't use distributed component models (3.00 / 3) (#19)
by pete on Sat Sep 30, 2000 at 08:11:44 PM EST

IMO, for stuff which isn't intended to be run on multiple CPUs (i.e. most of the software out there), the only component model you need is the shared dynamic library model already existing in all modern OSes.

Care to explain that a little? I don't mean to be rude, but that statement makes absolutely no sense.


--pete


[ Parent ]
Re: Why I don't use distributed component models (4.75 / 4) (#21)
by fluffy grue on Sun Oct 01, 2000 at 12:08:39 AM EST

Argh. I just spent the last fifteen minutes typing up a nice, complete response to your question, and of course, Netscape wonked up on me when I sent it. Typical Murphy's law. :(

ANYWAY. Rather than spend another fifteen minutes rambling about component models and abstract functionality clouds, let me try just summing up what I said before.

The reason to have a distributed component framework such as COM or CORBA is so that you have a vague notion of network-transparent message-passing between nodes on a functionality cloud. This makes sense for a lot of things. This also doesn't make sense for a lot of things. Some of the examples I went into painfully-excruciating detail about was how DirectX is a component model which doesn't act like one where it's important (using standard C-style callbacks in crucial places, for example), whereas OpenGL is a black-box shared library, which can under the hood use a distributed component model if it so chooses, and it does in the guise of GLX, the network protocol which encapsulates OpenGL calls in X11 messages.

I was being rather vague before. Then I was incredibly precise on my rebuttal. And now I'm just pissed. Tonight's not going very well for me. :P

But basically, if you want reusable components with incrementally-supported functionality and the like, why not just use a standard shared library? OpenGL has no problem being componentized without being a component model. Same goes for esound (libesound.so could theoretically just pass your sound commands to /dev/audio without any mixing or device sharing - and in fact, esddsp does the exact opposite, where it takes sound commands to /dev/audio and wraps it in esound's network transport), Xlib (libX11.so doesn't HAVE to try a TCP domain socket to connect to the server if it's on a separate box), and the like. Quake 3 doesn't give a damn whether I'm using Mesa, Utah-GLX, the DRI, Xi's expensive OpenGL implementation, or whatever, because it's just loading a shared library as a component. Now, the underlying implementation might use CORBA or the like as its network transport, but that's not strictly necessary.

As long as functionality is a black box, it shouldn't have to be blatantly a distributed component model. A distributed component model really only makes sense if the API is incredibly asynchronous (which OpenGL and X11 are) *and* most messages sent out have a response (which OpenGL and X11 don't) and there's better ways for the client to wait for a message response than to block.

Also, were it not for implementation details, there's no reason that CORBA couldn't be implemented on top of, say, MPI. (The main implementation detail being that, AFAIK, an MPI processor cloud is static - you can't add or remove nodes during the execution of an MPI program.)

So really I was being quite imprecise. I don't think that a component model need be exposed to ANY client-side program - all of that should be handled through a black-box library, and the only componentization that a program should see is the library itself. Of course, the library can be implemented through a distributed component model if it'd be useful, but unless something's running on multiple CPUs or otherwise has a lot of interprocess communication going on, the library using a distributed component model probably wouldn't be that useful at all, and even in many cases (such as Xlib) the overhead of using a distributed component model just might not be worth it over just doing some raw protocol (using, say, sockets); of course, for things like object embedding, type-handling issues make defining your own backend protocol not worth it, but for lightweight, send-a-bunch-of-small-commands-to-be-executed-whenever-possible protocols like X11 and GLX (OpenGL over X11), really a raw socket is all you need.

Is that more clear?
--
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Other ORBs left unmentioned (2.66 / 9) (#2)
by ksandstr on Sat Sep 30, 2000 at 01:09:39 PM EST

You forgot some free ORBs.

  • omniORB (v3 is GPL and has a kickass python binding too)
  • orbit (the one used by the GNOME crew)
  • I'm sure there's at least one ORBlet that implements a really tiny subset of CORBA, but I can't remember the name.


Fin.
Observations on CORBA and Distributed Programming (3.55 / 9) (#3)
by cysgod on Sat Sep 30, 2000 at 01:11:01 PM EST

In the end it comes down to the amount hassle to get a job done. CORBA represents a whole lot of hassle over a base system, with not enough gain to justify it. While CORBA does create a nice abstraction, there is no reason why many things it does can't be implemented in a much simpler manner.

CORBA is simply too much tool. The same way that emacs scares vi users, CORBA scares most C programmers. Although I think the intrinsic value of emacs is much higher than that of CORBA.

As I mentioned in a related article the barrier to good distributed programming goodies, is inclusion in the kernel. Trying to graft adequate functionality on in the userland creates an incomplete experience of distribution. Some things might get distributed, but some things are still left in the breeze, and if your box goes down you're hosed.

Trusted process sharing, and being able to move threads between machines as processor time becomes available, is the most viable, and most seamless way to handle distributed programming.

As for requesting 'objects' from databases and such, that just sounds like an extremely wrapper'ish task that could be handled easily by any platform. Go write an RFC on database interaction and get back to us.

I see CORBA and DCOM both as not enough utility for the added difficulty in writing code, and the overhead introduced by request brokers and middlemen is just huge. There are very specialized tasks where this overhead is worth it, but in the general case it is not. Hence, low usage of these tools, or usage just to get buzzword compliance.

CORBA as a means of relating data back and forth between hosts seems much less useful to me than XML. And judging by the usage of most programmers, plenty of people agree with me. So why isn't Distributed.net using CORBA or DCOM to interact with little cow clients everywhere? Because the tool is wrong for the job.

Re: Observations on CORBA and Distributed Programm (3.42 / 7) (#4)
by Carnage4Life on Sat Sep 30, 2000 at 01:41:47 PM EST

I see CORBA and DCOM both as not enough utility for the added difficulty in writing code, and the overhead introduced by request brokers and middlemen is just huge. There are very specialized tasks where this overhead is worth it, but in the general case it is not. Hence, low usage of these tools, or usage just to get buzzword compliance.

Spoken like a true Open Source hacker. I suggest reading my paper as an introduction to exactly when and how distributed object/component technologies should be used. Just because you have never written any software that requires communication between objects on different machines does not mean that DCOM/CORBA are hype. You may not realize this but you have used several applications that use Remote Procedure Calls (RPC) on a daily basis. Network name servers, file servers, web servers, email servers, nntp servers network time servers and database servers are a few examples of places where RPC is used.

Considering that DCOM/CORBA are the Object Oriented alternatives to RPC, similar to how C++/Java/Smalltalk are Object Oriented alternatives to C, I fail to how you can claim that they fail to provide utility.

PS: Usage of CORBA and DCOM is extremely high in the software industry. Simply because you haven't come across them in whatever capacity you serve in your professional life does not mean much. Besides the successful CORBA projects I have seen both in academia (for the Defence industry) and in industry (for a company that writes ERP and SCM software), there are numerous CORBA success stories that span the past decade. COM/DCOM/COM+ is used so extensively in the Windows world that it is easier to point to applications that don't use COM than does that do.

[ Parent ]
Re: Observations on CORBA and Distributed Programm (4.00 / 7) (#7)
by cysgod on Sat Sep 30, 2000 at 02:11:24 PM EST

Spoken like a true Open Source hacker. I suggest reading my paper as an introduction to exactly when and how distributed object/component technologies should be used. Just because you have never written any software that requires communication between objects on different machines does not mean that DCOM/CORBA are hype. You may not realize this but you have used several applications that use Remote Procedure Calls (RPC) on a daily basis. Network name servers, file servers, web servers, email servers, nntp servers network time servers and database servers are a few examples of places where RPC is used.


Wow. I'm a true Open Source hacker. Thanks.

The point is that CORBA is different than RPC. And while RPC is basic for plenty of important stuff, I question whether it is actually used in all the things you name. My name server does not use RPC, neither does my email server, same for my time server. A matter of fact the only thing I can think of that does use it is NFS. Other network FS projects (Coda comes to mind) have shown some short comings in RPC that needed to be patched.

It's the object-orientedness of CORBA that adds the baggage to system. RPC isn't exactly lightweight, but it's not too bad. CORBA is big. I'm sure in "the industry" that CORBA is in wide use on large projects that would be otherwise unmanagable. I'm not disputing that CORBA has some utility. However, for small projects trying to get simple tasks done, it's like using an elephant and steel cable to pull up a dandilion.

C++/Java/Smalltalk are all object-oriented alternatives to C. And despite growing favor for them what language is used in the majority operating system and embedded systems programming?

The example of COM use in Windows, is tainted since, if I recall correctly, COM use is mandatory to get certain functionality out of the OS. Functionality that could've easily been provided without COM.

Just because you have never written any software that requires communication between objects on different machines does not mean that DCOM/CORBA are hype.


I agree wholeheartedly. But CORBA will not solve world hunger. It is useful for object oriented programs that require communication between objects on different machines. That is a fairly small subset of the set of all programs. Most of the rest of us use good ol' RFC's and standard protocols to communicate between machines, using specialized protocols suited to the material being transmitted. CORBA adds a layer of indirection which, for many things is wholly unnecessary, and for a few things is vital.

To make an analogy, I need to haul heavy materials every once in a blue moon, when I do I rent a truck. I don't use the truck to go to work though because it is simply too much vehicle for my commute, it would get in the way, and the extra fuel it consumes would be wasteful. These tools have their purpose. The productive usefulness of CORBA is limited in scope, hence its usage is as well. Feel free to substitute C++/Java/trucks/convection ovens/...

[ Parent ]
Re: Observations on CORBA and Distributed Programm (2.50 / 8) (#8)
by Luke Scharf on Sat Sep 30, 2000 at 02:28:33 PM EST

Ever hear of Mosix? It's a nifty add-on to the Linux kernel that allows process migration between machines over TCP/IP.

http://www.cs.huji.ac.il/labs/distrib/

Of course, there are a LOT of issues when it comes to a neat trick with that like this. Probably not something you want to deal with when writing an office application.



[ Parent ]
I think that... (2.40 / 10) (#6)
by Didel on Sat Sep 30, 2000 at 02:11:10 PM EST

One of the reasons that CORBA has not caught on could be because of the Not Invented Here Syndrome. Just a thought.

Why I don't use CORBA ... (4.09 / 11) (#9)
by aphrael on Sat Sep 30, 2000 at 03:14:47 PM EST

ObDisclaimer: I work professionally with DCOM

When I first got into distributed programming, I took a look at CORBA --- there are a number of things it seems to do better than COM, including (my favorite) allowing exceptions to propogate across the wire and be repackaged in the language of the recipient. But I quickly gave up and retreated back into the COM world. Why?

1. politics. CORBA presented itself as being the universal cross-platform cross-language standard, and then a few years ago OMG (the object management group, which theoretically safeguards the standard) announced that Java was the only language which mattered because everyone would switch over to it in the future. Thus, CORBA became linked with Java, and other languages became less important. (The company I work for merged with a major CORBA vendor, but it took *years* to get them to support our primary programming language --- if it wasn't Java or C++, they just didn't care).

2. Poor documentation. At least at the time, all of the books I could find on CORBA were directed at *managers* explaining *high-level concepts* without any low-level technical details at all; you could learn why CORBA was cool, and what it was capable of, but not how to take advantage of those capabilities. To be fair, early documentation on DCOM suffered from something of the same problem --- but DCOM moved beyond that, and CORBA didn't, at least not while I was paying close attention.

3. Ugliness. C++ CORBA code looks ugly.

4. Lots of overhead. Of course, DCOM has the same problem --- but in DCOM's case, most of it is integrated into the operating system. It would be *cool* if Linux had something similar integrated into the OS, but because of #3, it is unlikely to be CORBA.

5. CORBA is difficult to use. There are lots of poorly documented caveats, and you end up being tied to specific implementation details of different ORB vendors (so much for replaceable, extensible architectures!); at the end of the day, it's easy to throw up your hands in irritation and say 'i should have just done this directly with sockets'.

Most of these problems apply to both DCOM and Corba, which makes me wonder if they are inherent in distributed architectures?

Re: Why I don't use CORBA ... (4.00 / 6) (#13)
by ksandstr on Sat Sep 30, 2000 at 05:58:23 PM EST

Regarding CORBA being "linked" to Java...

I must disagree. The current CORBA spec doesn't contain much stuff that couldn't be implemented in C++, python, perl or even straight C without too much trouble. The OMG seems to have updated the C++ mapping specs pretty well even after the announcement that you refer to.

Besides, with (D)COM, you're pretty much stuck with an interface that is bound to change because of the parent company's whim; there's no standards committee or group to provide sufficient inertia. But that's just the anti-lock-in section of my brain talking.



Fin.
[ Parent ]
Re: Why I don't use CORBA ... (none / 0) (#28)
by coryan on Mon Oct 02, 2000 at 12:18:15 PM EST

ObDisclaimer: The original poster works with COM, I work with CORBA

> 1. politics. CORBA presented itself as being the
> universal cross-platform cross-language standard,
> and then a few years ago OMG (the object management
> group, which theoretically safeguards the standard)
> announced that Java was the only language which
> mattered because everyone would switch over to
> it in the future

   Can you please provide a reference for this statement? I think you may have misinterepreted something, the OMG has shown a long commitment to multiple languages.
   Even if somebody from the OMG said that, it was probably a mistake, and their actions (or the actions of their members), seem to prove it: the C++ mapping is constantly revised, they are currently adding Python, Lisp and CORBAscript mappings. Yes, Java and C++ are payed a lot more attention than other languages, probably because they are some of the most popular OO languages around.

> Thus, CORBA became linked with Java, and other languages
> became less important. (The company I work for merged
> with a major CORBA vendor, but it took *years* to get
> them to support our primary programming language
> --- if it wasn't Java or C++, they just didn't care).

   And it was probably a reasonable thing for them to do, after all they are a *vendor*, if they support a not-so-popular language they sink a lot of money for little benefit. Now, this looks more like a problem that your company had than a problem with the technology, right? If you haven't been "merged" with this CORBA vendor maybe you could have switched to some other vendor that was more willing to listen, right? Or get a Open Source implementation and change it to your needs? To be fair maybe you couldn't do any of them, I would still argue that your company was in an exceptional situation in that case, and it wasn't a problem with CORBA per-se.

> 2. Poor documentation....
[snip]

   Yes, that used to be a problem, not anymore, please check Henning & Vinoski's "Advanced CORBA Programming with C++", even if C++ is not you cup of tea this should be a very good book to read.


> 3. Ugliness. C++ CORBA code looks ugly.

   And COM looks better? Or have you looked at COM's IDL files?

> 4. Lots of overhead....

   Maybe the first generation ORBs where like that, second and third generation ORBs have reduced overhead to a minimum. Around 100 microseconds per call and some people claim even less than that.

> 5. CORBA is difficult to use.
[snip]

   This is one of the arguments I can relate more closely to. However, it has been my experience that when people say "CORBA is too hard" what they really mean is "Distributed Computing is too hard". CORBA make distribution easier, but it does not (and partly it cannot) solve the "inherent complexities" of distribution, such as variable latency, partial failures, concurrency, etc.


> Most of these problems apply to both DCOM and
> Corba, which makes me wonder if they are inherent
> in distributed architectures?

   I think you nailed it. Some of the problems that you refer to, like poorly documented interfaces or weak implementations that force you into a corner, are just the current state of the technology. But the really hard problems, like security, quality of service, distributed transactions, and partial failures are there to stay, the technology can make it easier to deal with them, but no amount of technology will make them dissapear.


[ Parent ]
Re: Why I don't use CORBA ... (none / 0) (#30)
by aphrael on Mon Oct 02, 2000 at 03:57:38 PM EST

Can you please provide a reference for this statement? I think you may have misinterepreted something, the OMG has shown a long commitment to multiple languages.

No reference: there's nothing easy to find on the OMG site pre-June 1998, and the last time I seriously looked at Corba was in 1997.

Now, this looks more like a problem that your company had

Oh, absolutely: it was a textbook case of a badly executed merger. But then again, the title of the post is "Why I don't use CORBA" not "Why you shouldn't use CORBA"; your mileage may vary, mine was just particularly bad.

(Regarding bad documentation: Yes, that used to be a problem, not anymore,

That's good to hear.

And COM looks better? Or have you looked at COM's IDL files?

I try to stay away from IDL. One of my jobs is to maintain an IDL parser (for COM IDL); the language is irritating to deal with in both of its flavors.



[ Parent ]
Advanced CORBA Programming with C++ (none / 0) (#32)
by cthulhu on Wed Oct 04, 2000 at 10:52:33 PM EST

To reiterate coryan's statement, I'd highly recommed Henning and Vinoski's book (the title is the same as the subject above) as well. If you want concrete examples and tons of code snippets, this is a great source.

[ Parent ]
Why CORBA? (2.57 / 7) (#10)
by PresJPolk on Sat Sep 30, 2000 at 03:17:14 PM EST

Maybe CORBA would be used more often, if people had a use for CORBA.

Your average user's desktop isn't on a network most of the time, let alone needing a distributed component framework.

That's a big part of why KDE dropped CORBA. KDE is trying to be a desktop environment, not a distributed computing platform. Like fluffy grue was saying, CORBA provides nothing for a standalone user's desktop that shared libraries (i.e. KParts) can't provide.

Distributed components are a niche technology. Don't expect people to use a jigsaw where a table saw is called for.

Re: Why CORBA? (4.28 / 7) (#15)
by J. J. Ramsey on Sat Sep 30, 2000 at 06:50:41 PM EST

The problem is assuming that a user's desktop is going to be standalone. This may be true for a home user, but not necessarily for desktop computers in a business setting. Think about some of the companies behind stuff like CORBA: Sun, HP, IBM. Think about the kinds of computers they sell, things like servers and workstations connected by networks. These guys probably wanted CORBA to be network transparent because it was useful to them.

IMHO, I think that KDE is a bit shortsighted about network transparency. This particular piece from Simon Hausmann's short explanation of Kparts kind of bugs me:

"Noone[sic] is going to embed a remote spreadsheet document into a word document, running on a machine on the other side of the ocean. This is a nice dream and it is certainly technically interesting (no doubt about that), but it is not what the average desktop user really wants. The priorities are different here."

Maybe a "machine on the other side of the ocean" is unlikely, but what about a machine on second floor in some company's building, where an accounting department's server is? Someone else pointed out to me that a remote spreadsheet document from a "machine on the other side of the ocean" may not be so farfetched. Imagine an accounting report for a multinational company centered in the U.S. but with subsidiaries in Asia and Europe. In such a scenario, embedding spreadsheets from some remote machines from the Asian and European subsidiaries is not so off the wall.

IMHO, one should be really careful about statements like "No one will ever need [fill in the blank]."

--I am a fool for Christ. Mostly I am a fool.--
[ Parent ]
Re: Why CORBA? (3.00 / 4) (#16)
by PresJPolk on Sat Sep 30, 2000 at 07:28:20 PM EST

The problem is assuming that a user's desktop is going to be standalone. This may be true for a home user, but not necessarily for desktop computers in a business setting. Think about some of the companies behind stuff like CORBA: Sun, HP, IBM. Think about the kinds of computers they sell, things like servers and workstations connected by networks. These guys probably wanted CORBA to be network transparent because it was useful to them.

I agree that distributed components can be useful in such settings, as part of greater computer frameworks sold by the big iron companies, but the question was about open source software. The heart of open source software is still the home hobbyist. The home hobbyist rarely writes software specially suited for the "enterprise."

IMHO, I think that KDE is a bit shortsighted about network transparency. This particular piece from Simon Hausmann's short explanation of Kparts kind of bugs me:

"Noone[sic] is going to embed a remote spreadsheet document into a word document, running on a machine on the other side of the ocean. This is a nice dream and it is certainly technically interesting (no doubt about that), but it is not what the average desktop user really wants. The priorities are different here."

Maybe a "machine on the other side of the ocean" is unlikely, but what about a machine on second floor in some company's building, where an accounting department's server is? Someone else pointed out to me that a remote spreadsheet document from a "machine on the other side of the ocean" may not be so farfetched. Imagine an accounting report for a multinational company centered in the U.S. but with subsidiaries in Asia and Europe. In such a scenario, embedding spreadsheets from some remote machines from the Asian and European subsidiaries is not so off the wall.

IMHO, one should be really careful about statements like "No one will ever need [fill in the blank]."

You don't need CORBA for document sharing. SMB, NFS, and other shared filesystems do that just fine. For sharing data that might be modified, an RDBMS will do the job.

But, if the time comes that distributed components become needed in KDE, then the developers will dust off MICO, and use CORBA where it's needed. For the design goals envisioned by KDE right now, though, the overhead of CORBA is just a waste.

Will Hausmann's statement be remembered with "640k ought to be enough for everybody?" Will the N in GNOME be remembered as the fatal flaw? I guess we'll find out. :-)



[ Parent ]
Proof. (2.77 / 9) (#11)
by Crutcher on Sat Sep 30, 2000 at 03:19:04 PM EST

A lot of the problems with distributed computing comes down to proof. Your average Hacker type likes provable systems (even if they dont do the math themselves), they have a certain 'feel' to them, and the feel is that their 'is' and answer to a given question.

Distributed computing is not a provable function space, and as such, that 'feel' is missing. Untill we have some really nifty math to let us fake it again, there wont be a good 'Distributed Component' system that doesn't feel like C++ on a bad self-congrajulatory trip.

Translation: This problem will not go away, untill it is as easy to throw components arround a network as it is to throw threads around a system (with out it looking like legos). The thread problem is STILL not quite solved.

(Plus, who in hell named this crap? 'ORBS?', I mean, come ON.)
Crutcher - "Elegant, Documented, On Time. Pick Two"
Know what's fun? (1.83 / 12) (#12)
by simmons75 on Sat Sep 30, 2000 at 03:49:11 PM EST

I tried to use GNOME on my machine in a dorm room back in my days of living on a college campus. It was real fun logging in when Something Bad Happened(TM) on the resnet (more often than not, something was wrong :^) and Panel stalled out for 10 minutes. Yay, thank you, GNOMErs for adopting CORBA. :^P
poot!
So there.

Re: Know what's fun? (3.25 / 4) (#22)
by zapman on Sun Oct 01, 2000 at 11:51:35 AM EST

I don't recall the exact solution to this problem, but it involved having a sane networking setup, including nameservices, and certain hosts in /etc/hosts. IIRC: What you were waiting on was a reverse lookup of your box.

However, that's a fuzzy memory.

Jason
-- The request of a friend in need, is done by a friend in deed.
[ Parent ]
Hard to post-implement? (3.40 / 5) (#14)
by cybaea on Sat Sep 30, 2000 at 05:59:05 PM EST

Ehh, how about this reason:

Many Open Source projects start out as a single person's pet project. Think of perl and linux. For this you probably do not need CORBA. So it isn't designed in from the start. Then the project grown and "you know, it would be really neat if we had support for something like CORBA, but I guess it's too much hassle to add it on now -- would need big design changes"

It's hard to add CORBA when the solutin wasn't architected with this in mind from the start. So nobody uses it. So nobody uses it. So nobody knows it.....



What about Berlin? (3.00 / 5) (#17)
by MenTaLguY on Sat Sep 30, 2000 at 07:41:16 PM EST

Berlin is a very heavy user of CORBA, and it looks like it's working out pretty nicely both from a complexity and performance standpoint. (and we get network transparency more or less for free, yay!)

So, there's at least one major open source project using CORBA.


...ceterum censeo delendam esse X11.
It's VERY difficult..! (4.70 / 10) (#23)
by snowlion on Sun Oct 01, 2000 at 07:50:26 PM EST

(Consider this a preview of a rough draft.)

I've read Miguel's papers, even printed them out.

I fully agree: a component architecture is critically necessary. People who say "they don't see the need for one" are right: they don't see the need for one; that's a large part of the problem.

This is a hurdle. Its a major problem that people don't understand that you can't just shove some source at someone and say, "Here; Rip what you want from here", and it's a problem that people can't understand the need for software programs to communicate with one another, and document formats, and a million other things. But, I really don't think people have been given much of a chance to see these things.

It's just way too difficult to learn and use CORBA and Bonobo (as they exist right now).

Let me post my story:

I read Miguels article "Let's Make Unix Not Suck". Indeed; I'm looking at a print out of it it right now, and it's taken a central place on my desk for some time. When I teach UNIX and Python to my students, I recommend it to interested students. Needless to say, I fully and completely agree with everything there.

So, I decide, "I think I'll learn a little more about this; it shouldn't be too difficult." I follow the references embedded in the "Let's Make Unix Not Suck" document (unfortunately, there isn't a "References" section at the end of the document...), and wind up at Miguel's document on Bonobo. I thoroghly study it, critically think about it, annotate it, look things up on the web, ask questions, what now. I'm now looking at my print out of Bonobo. Wonderful! I completely absorbed it. But, that document isn't enough to go on. So, I trace deeper.

GNOME & CORBA. Mathieu Lacage and Dirk-Jan C. Binnema. Straight from the gnome.org web site.

I wish I could say that I was looking at a print-out of it right now. I really do. Unfortunately, I can't. I would, it's just that I would feel too guilty, printing a 300 page tomb at work. I DO however have 61 pages of it printed out. It's really thick. I've managed to sustain the concentration to read 20 pages of rather stiff documentation. (Let me give the authors of the docs a hint: DIAGRAMS and tables. Too many words where a simple diagram would have done the trick.)

Note that, up to this point, I still haven't seen a single sample app, except for a little program to deliver an int over a network that is 2 pages long and involving several steps (building interfaces, skeletons, stubs, and finally implementing a program). I've seen clips of incomplete interface codes here and there, but nothing real; nothing solid.

Hmm. Source code. That'd be nice. I scour the Internet. What?! Google doesn't show mountains of web pages with little programs using bonobo and corba? Ack! "I must be typing something in wrong," I think, and try a few permutations of search.

Nothing. Nada.

Okay, now, given the problem, I try something out: How about IRC chat rooms? Granted, I've been ridiculed for asking "simple" questions about GTK+, and I've been given several "What the fuck are you asking us for- haven't you read the mountains of documentation? You aren't 1337; get out of here!" (It turned out, there was no documentation that addressed my questions...) But, I thought I'd try IRC. "Luckily", in IRC, people don't find Bonobo and CORBA to be quite so obvious as well, so I'm spared the ridicule. When I ask about finding bonobo and CORBA components, the answer I get back is this:

There are none.

At least, there are none that are seperate from there apps. Gnumeric has a few interfaces. So do a few other programs. Do a "locate idl" and see what you come up with, and that's about all there are. I have to grep out the "/mnt/.../micros~1/vc98/*.idl"'s to find the very very few that have been implemented in GNOME: A calculator, some control panel stuff, and some Gnumeric stuff.

Pathetic. Terribly sad. I feel personally offended and hurt.

This brings me to my current model of OpenSource developement, and solution, to the problems at hand.

There are categories of OpenSource developers:

  • Those without lives. These people are experts at their fields because they have no life outside of them. I suspect that these are the people who were telling me to fuck off. They are brilliant in their world, but are socially disfunctional. They cannot understand that someone doesn't understand what they do. They don't want or need the help of those outside of their field.
  • Those who are part of a team that meets with each other. Miguel de Icaza and a band of geographically close members are able to talk with one another frequently. From what I can tell, MDI (Miguel de Icaza) is not a social outcast. (Indeed, I find him to be quite noble and I think we need more people like him. He is honestly comitted to the ideals of Free Software, and wants to share information. He is not an elitist.) MDI and Co. meet physically, or at least on the phone (again, this is my theory), and thus there is a RAPID flow of communication amongst themselves. They can build their software rapidly. Note that, now, MDI & Co. are working at either Red Hat full time, or at Helix Code. The problem appears when they try to communicate with the outside world. Which leads to the 3rd type of OpenSource/Free Software developer.
  • The Lost. That's me. That's several others who want to help, but can't. We wish we could shunt off our life to help out for the cause, but we can't, because we know it's foolish. We'd love to meet in the Physical world, but we can't, because we're physically distant. (Actually, I've done something about this myself; I'll describe it in a bit.) It just takes way too long to read all this stuff without pointers to what can be ignored, what is essential, what is good, what is bad. I worked for 2 months on a project before learning that the principle libraries backing it were obsolete. 2 months! Disgusting. We are helpful people. We are smart people. The problem is, we're just NOT in the flow of communication. This is the principle reason why companies will continue to surpass Free Software developers: Everyone building software is together. Sure, you can admin your systems from afar, but develop software? Unless you are prepared to throw your life into it and completely lose touch with society (I know a few of these people; some of them are good friends of mine), you don't have a chance.

Now, what do we do for the 3rd group? I believe that if OpenSource is to survive, the 3rd group will need to be tapped. I think that the carrying capacity for the 1st group has been met: We won't get any more of them. They are a special breed, and I don't mean this in a good way. The 2nd group can expand as long as the market will take it, but I think that the OpenSource market is reaching equilibrium, and it'll be at carrying capacity pretty soon. Which means, we need to tap the 3rd part. And Lord, do I believe that it's untapped. I see people every day who'd love to help, but just can't, because the penetration is too difficult.

Allow me to present my ideas for a solution:

It's all about groupware. The problem is communication, the solution is groupware. We need better collaboration, pure and simple. The only thing that the companies have on us is proximity. They can shout down the hall back and forth more times in a minute than I can through email in a month.

IRC is NOT the solution, just as files are not the solution to disorganized data. Allow me to present a vision of the future of OpenSource programming:

I want to make a GUI for a little app I've made. I go into Glade 2004, and there are hoards of little icons and what not. I place some items in there, and as I do so, I can browse documentation about the icons. Oh, that's odd- the documentation for the GtkEntry widget has a typo in it. I correct the typo, and up pops a little dialog: "Would you like to submit this to the official text?" Yes, I say. "What kind of correction is this?" I read a list, and select "typo". "Thank you". I continue reading the text.

Allow me to digress for a moment: Behind the scenes, several people daily are using glade. When glade started, there was little documentation, though people quickly discovered that they could add to the documentation themselves. It wasn't like WikiWiki; people couldn't just erase everything: submissions were mailed to servers, where managers could say, "Yes, yes, good, let it pass," or, "No, I'm sorry, but we won't erase everything here and put "Bub Rul3z" up in it's place.". Originally, there weren't many docs, so people had to communicate. They did so by saying, "Chat with everyone willing, who's using glade right now." It turns out that, in the future, people are marked up, not just document entities. And one of those markups is "using glade right now and willing to talk." So someone asked the fellow OpenSource afficionados: "Anyone know how to use a GtkEntry?" Someone volunteered information. It turned out he was busy, but he could share a little information. The person who asked used the seed information they had, grew it, and then wrote the GtkEntry documentation from what they had, and submitted it through the glade app. (Of course, Glade is using component technology, so Glade doesn't have to rewrite all this component stuff, which is used in EVERY program in 2004. Those people who worried about "interdependencies" (reads: reuse) who enjoyed running make config's died out mysteriously in 2002.)

Excuse me; so that was the story of how my GtkEntry stuff got there in the first place. NOTICE how... Nobody had to enlist themselves on any mailing lists. NOTICE how... Nobody had to even open up a mailing program. Notice how people didn't have to log in to IRC, get distracted, and then FINALLY CHECK to make sure that there were actually glade people present. Now back to my story.

So I've made my GUI. Everything was documented, and I was able to talk with people. Okay, this post is getting a little long, so I'm not going to go further. Needless to say, I will be expanding these ideas in future web pages...

All of this is called GroupWare. Currently, GroupWare consists of ICQ, IRC, and e-mail. GroupWare is in the stone ages. Put a little meanly, I keep meeting people I'm not interested in. Put kindly, I can't find the people that I need to talk with. I have to wade through stuff. In the future, GroupWare will make collaboration over the Internet easier. GroupWare will enable OpenSource development to match, and then exceed, the proprietary developers of the world. (Can you imagine Microsoft allowing customers to correct typos for them, or improve their manuals? Unlikely...)

Most likely, open source people won't implement the original groupware that we need; we are too feeble right now, as evidenced by our inability to dissemenate knowledge on how to build components. But, even if we don't build groupware, companies will. We should use the groupware they provide, when it becomes available.

Now, this is very nice, but, what, as individuals, can we do right now?

Again, accepting the premise that communication is the problem right now:

  • Move to a metropolitan location. I moved to Seattle. (A month ago, I moved to Kirkland, but it's practically the same thing.)
  • Start a group. I'd love to be able to say "Join a group", but you probably can't. "But what about the Linux users groups?" They are great, if you happen to be a system administrator, and you happen to enjoy whining about MS a lot. But that doesn't cut it. In my case, I've decided to start a group. I started free classes in UNIX and Programming in C & Python 6 months ago. We meet twice a week; Mondays for advanced students, and Saturdays for all students. The web pages are at taoriver.net/unixclasses, but are down right now until we get DSL hooked up at the new apartment. (Google still has the classes in it's cache.) So far, I've taught 3 people to program in Python rather well, and they have a good foundation in C. In total, I'm working on a group of 7 right now. One of the people in the advanced class is helping teach the beginners class as well. We have made some libraries that I'd love to post to the net, but can't right now. (Again, the DSL.) We'll soon be using the ArsDigita community system to set up some class space at a student's home web site. So far, we are doing rather well. I hope to penetrate CORBA and Bonobo some day, make it in, and tear it up, so to speak. It's just impenetrable right now. That's the whole of it. Search the web for Bonobo components, I dare you.

    People say it's the interdependencies, and people say it's bloated, but that's not really it. That's just whining. The truth is, it's just too hard to use. Our current reserves of type 1 and type 2 programmers are all full right now, and time isn't being spent on making CORBA easier to use right now. Sad, but true.

    At any rate, this is probably a little longer than anyone wanted to read. If I posted this to /., I'd probably have a Score: 0 by now; I notice that my best posts at /. get Score: 2, and my worst posts get Score: 5. Hopefully someone will read this, and respond to this.

    I've got it on my priority wall to write all these ideas together and post them to the web; I'm going to consider this my rough rough draft.

    Please, comment on this. Please help me out. I'm working very hard on this, and I really want to see the vision of OpenSource software succeed. My model may be incorrect, and is completely open to re-evaluation. Maybe I'm just doing things wrong. (I do, fully, believe that you shouldn't have to throw away your life to contribute to OpenSource software and documents; I believe that we can harness "microwork".) Please critique it. Not personally, but here, so everyone can see it. I sincerely thank you for reading this far, Lion Kimbro


    --
    Map Your Thoughts
Re: It's VERY difficult..! (2.50 / 2) (#24)
by Carnage4Life on Sun Oct 01, 2000 at 09:04:33 PM EST

Hi,
Thanks for the lengthy reply. Coincidentally I am actually working on an app that satisfies the problems I see with today's GroupWare. My app isn't as ambitious as yours and is merely an IM which is tied into a web forum. Descriptions of it are here (I apologize if the HTML is weird, it was generated from MS Word).

I think your biggest problem won't be creating your application but actually getting people to use it. I suggest trying to get it added to sourceforge or one of the versions of CVS. Please send links where you have described your app in more detail.

[ Parent ]
Re: It's VERY difficult..! (2.66 / 3) (#25)
by snowlion on Sun Oct 01, 2000 at 11:15:28 PM EST

It's fascinating that we are interested in the same things.

I am glad that I finally got my ideas out there, though I apologize for not presenting them clearly.

"Glade 2005" doesn't exist; I meant it to be an example of what I imagine we will have in the future. I didn't mean to suggest that this is software that I, or anyone else, is actually working on. However, I do imagine that the OpenSource world will have the software some day in the future. My estimate is 2005.

I described the system in the paper as a solution to the current lack of communication, which itself leads to such difficult technologies as CORBA/Bonobo, which nobody outside of Helix Code or Red Hat can use (unless they are emplyed full time to decrypt it).

I suspect that after 1 or 2 years, someone will make CORBA/Bonobo easy enough to actually do useful things. Sufficient ease of use: Make Python IDL bindings, make them dirt simple to use, and form a collection of tutorials and source code illustrating usage. At the very least, they need to allow us to make components in Python that can be incorporated into, say, Gnumeric or AbiWord. We also need to be able to include the components through Glade. Quite a tall order, but I think it will come.

This is off the top of my head, but I believe we have the following requirements before we can obtain the system I described ("Glade 2005", or any of it's variants):

  • A distributed component architecture. CORBA's what we want, but as they say, "Higher than the Truth is True Living." CORBA's only a corpse as long as it is dead to us, the OpenSource world. It's just necessary architecture.
  • Easier to use and install community systems. ArsDigita is doing well; a student of mine was able to figure up and set up their beginning system in a weekend. But it needs to be easier, and common place. It is good to see that WebDAV is coming along as well.
  • Awareness of Collaborative systems software. It's just appearing, with MS .NET, the RedHat Network, ICQ, the twisting of HTML and UseNet (both of which have been adapted for different purposes than they originally had), WikiWiki, and a host of interactive useful pages on the Internet. People need to understand what it is and what it's useful for before they can be excited about it. (I'm firmly convinced that we're just playing through ideas that were roadmapped in the 60's and 70's...)
  • Scripting languages and libraries with collaborative components. I'm sure there are many around, but I haven't heard of them, and that's part of the problem. At any rate, I need to be able to write perl scripts that ammount to: IF lion@speakeasy.org AGREESTO "Dear Lion Kimbro, Shall I run a script for you?" THEN PRINT "Lion Agreed", or even things like IF @emailaddresses AGREESBYSIMPLEMAJORITYTO $message THEN do_something_complicated(). We need languages or libraries or components that can model the needs of communities. I suspect that a "worse is better" approach would do wonders here; Just look at WikiWiki. No concern for security, and no complex capabilities, just pure and simple application. Easy to break, but incredibly useful.
  • Standardized Protocols and Data Structures. Whether the standards come about through someone just writing a cool app and then that's the standard, or through an RFC process, I don't really care. We just need SOMETHING. We have iCalendar for calendars, and iCard. That's a start. I think that some standard data structures for people and organizations are necessary as well. If you know of any, please refer them to me.

Personally, I want to collect these thoughts, write up an article based on all of them, make it nice and neat, and then post it to FreshMeat. Before I do so, I need to read the ORielly on GroupWare, get my DSL hooked up, and write a few more notes on scrawled paper at work. I've got a large collection of scrawls allready that needs to be consolidated into one place. (Hmm; In the spirit of Release Early and Often; I'm not so sure that I should wait for all of these steps to be finished.

Unfortunately, I have only skimmed over your paper. I will look at it in more depth after I post this. Would you put your e-mail address on it, so that people (ie myself) can write back to you about it, without having to check Kuro5hin? Based on my brief look at it, it looks exactly like the kind of thing I believe we need.

Again, I'm sorry, I didn't mean to imply that I was actually working on the software I described. I wish it was in the realm of feasability right now, but I don't think it is. Thank you very much for your reply, Lion Kimbro. =^_^=


--
Map Your Thoughts
[ Parent ]
Re: It's VERY difficult..! (none / 0) (#26)
by Carnage4Life on Mon Oct 02, 2000 at 09:50:29 AM EST

If you are interested in beginning research for your app without waiting for Bonobo to mature, the OMG has announced the Corba Component Model which is a superset of Enterprise Java Beans. Currently examples of code are lacking but I have found this site to be my best resource so far.

As for Python IDL bindings look at this ORB that includes language mappings from CORBA to Python, Fnorb.

[ Parent ]
Re: Python and Corba (none / 0) (#33)
by phoenix on Wed Nov 01, 2000 at 10:24:12 AM EST

I wouldn't recommend looking at Fnorb as it is not free software - OmniORB2 is the way to go. The language binding for CORBA is available from OMG - and I did manage to find it afew weeks ago... Ah! There is a link from the OmniORB for Python page. OmniORB2 is free software.

[ Parent ]
The problem with CORBA et. al. (none / 0) (#27)
by sergio on Mon Oct 02, 2000 at 10:42:46 AM EST

The problem with CORBA under UNIX (or any OS) is that there are no standard ways to
register or start-up a componebnt so that another application can find it. Yse, there is POA, BOA.... blah, blah, blah.

The real solution is to have some facility like inetd, inetd.conf and /etc/services which
provides the basic mapping of the interface and the starting of a component.

Another large problem that is not addressed by most component architectures is how to authenticate resources. Indeed this would solved if there where some way to provide the
chaining and layering of services, like it is done with servlets.

Anyway... it won't be done before all other stuff has been tried out before.



The real reason it isn't done? (none / 0) (#29)
by trhurler on Mon Oct 02, 2000 at 12:53:56 PM EST

As it happens, I think we should avoid these "architectures" for most purposes, but my reason is not the one people are actually using for not doing so.

Their reasons are: first, they don't know the technologies, and second, they are -famously- resistant to new technologies unless/until they prove themselves, and sometimes even after that. As yet, none of them has done so; the only mature publicly visible component model in the world has caused the world's least reliable operating system. That's not a good track record.

Now, -my- reason for avoiding such architectures is quite simple: I have never been convinced that you can produce a large-scale component architecture that is as reliable and secure as the systems I use now, and I have no use for unreliable, insecure software. You can point to all the standard bull about how this or that new design is going to be mecca: until I see it working in its full glory, I can't/won't/don't care AT ALL. There are too many new projects, too many "brilliant ideas," and so on for me to track them all, and if/when someone succeeds, there will be plenty of opportunity to benefit by that.

--
'God dammit, your posts make me hard.' --LilDebbie

In my experience... (none / 0) (#31)
by pjc on Tue Oct 03, 2000 at 01:05:10 PM EST

The reason that CORBA is not used in Open Software is because the OMG is a closed group. I find it an insult that it costs thousands of dollars to participate in the organization. This makes its basic purpose closed to the general public. It reminds me of the OSF, which is pretty much vapor, now.

The big difference between the OSF and the OMG is the fact that the OSF collected royalties for its work. The OMG just dictates specs from 'Mount Olympus'.

Another issue is that the OMG has specs for just about anything. To call it bloatware is an understatement. I think it is more like 'World Domination Ware'. Have you ever perused the specifications available? It boggles the mind. Who is supposed to follow this nonsense, and who is going to code it all? Most of the specs are from some well-funded corporation that pays rediculous fees to have a few of their development organization post 'research' papers about some useless thing or another so they can get a bonus. This is exacerbated by the continuous specification waffling that has happened since Sun abandoned CORBA and has forced the OMG to kneel at the EJB alter. Sun turning its back on CORBA in favor of persuing destruction of what McNeely calls the 'Deathstar' left the OMG in limbo--but that is another discussion.

For CORBA to be successful in Open Software, the specification control process must be removed from those currently in control, removed from the whims of corporate vendettas and philosopy-ware designers, and put on a realistic feature schedule by Open Software developers--by people who implement the code.


pthread_exit( (void *)0 );
Mico (none / 0) (#34)
by phoenix on Wed Nov 01, 2000 at 12:05:13 PM EST

If you are looking for the home of Mico it is http://www.mico.org/

CORBA and Open Source | 34 comments (34 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!