Slashdot Mirror
Should IBM's SOM/DSOM Be Open Sourced?
Esther Schindler sends a note about two journalists for very different publications (herself one of them) urging IBM to open-source, not all of OS/2 — they've consistently refused to do that — but instead one of its most powerful features: SOM, the System Object Model. Steven J. Vaughan-Nichols writes at desktoplinux.com, "IBM, I'm told by developers who should know, still has all of SOM's source code and it all belongs to IBM. It's because IBM doesn't have all the code for OS/2 and some of it belongs to Microsoft that IBM open-sourcing OS/2 has proven to be a futile hope." And Esther Schindler takes the developer angle in a blog post at CIO.com: "Could the open-source community use a library packaging technology that enables languages to share class libraries regardless of the language an application was written in? I dare say it could, especially since the code to accomplish that goal was written (and shelved) more than ten years ago. All it takes to make that code available is to ask IBM to release SOM and DSOM as open-source." What are the business issues that would convince IBM to assent?
You must mean AIX - or you are predicting the future when IBM open sources SOM so your statement comes true...
and so has Apple, however Steve Jobs ended that "idea" when he returned to Apple...You mean Taligent? Which was an IBM & Apple co-project?
Microsoft has a very similar concept COM+You mean MS markets something they pretend is very similar, but any programmer who has used both will tell you they are light years apart, and that no matter how many ++++++++ MS adds to the end of COM, or how many times they change the name of OLE, it still will be light years behind SOM/DSOM.
You ARE on the right track with all of your comment - your just heading the wrong direction...
StarTrekPhase2 - The Five Year Mission Continues!
.net and mono are functionally equivalent to a SWIG wrapper - a bit easier to deal with, but similar nonetheless.
this is a bit different. for one, it allows you to redefine how an API is implemented. imagine a generic database API. instead of programming to a client library, all software can be written to a single standard API that then has its guts replaced with a simple call to be database specific. need to move from mysql to postgres and have 30-40 different maintenance programs and scripts that are programmed to deal with the API? simple, replace the guts of the API with the postgres API, and you're back in business. no need to write wrappers or even recompile.
The following quote supports the parent's point The most notable difference between SOM and COM is support for inheritance -- COM does not have any. It might seem odd that Microsoft produced an object library system that could not support one of the most fundamental concepts of OO programming, but they did have their reasons. The main issue is that it is difficult to know where a base class exists in a system where libraries are loaded in potentially random order. COM demands that the programmer specify the exact base class at compile time, making it impossible to insert other derived classes in the middle (at least in other COM libraries).
SOM instead uses a simple algorithm, looking for potential base classes by following the inheritance tree and stopping at the first one that matches; this is the basic idea behind inheritance in most cases. The downside to this approach is that it is possible that new versions of this base class may no longer work even if the API remains the same. This possibility exists in any program, not only those using a shared library, but problem can become very difficult to track down if it exists in someone else's code. In SOM only solution is extensive testing of new versions of libraries, which is not always easy.
Smalltalk / Squeak has been doing something similar for years. Anything in the system can message anything else. System components / GUI elements can be freely inspected, subclassed, modified - and all on the fly while the system is running. Of course, this means that all source is very literally open (other than virtual machine primitives).
I would note that you can do all those things on Windows with COM. In fact that's how transparent PNG support was added to Internet Explorer, and is why you have to invoke them in such a funny way (MS could have done a better job of the IE/COM integration in the images department).
Anyway, COM isn't hard to learn - it's actually incredibly simple. It's all the OLE2 related stuff that makes a mess of programming visual components. Steer clear of automation, OLE and it's pretty easy to knock up stuff in COM.
Linux Desktop environment use bonobo implementing some of its services to achieve reusability and that too is not universal. (Gnome uses it).
No, Bonobo failed and is being phased out: http://live.gnome.org/Bonobo
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
I did two contracts with IBM in the early 90's, one on the OS/2 2.1 change team. In both I "got" to deal with SOM and its implementation source code. It's a giant nasty C macro & function pointer hack. OS/2's Workplace Shell was very cool but the underlying implementation was pretty nasty stuff. One of my fixes was dealing with how slow it was populating icons in folders. SOM is a good example of the "Prototry" anti-pattern where one does an initial implementation of a cool trick then ends up shipping & extending it rather than ever bothering to architect it right in the first place. I can understand why IBM doesn't want this source out in public. FWIW - I also had to deal with some of the Microsoft source code, especially device driver stuff. Was the worse C code I've ever seen in production...
If you like SOM & Workplace Shell features you'll find it far easier to implement on top of Qt/KDE or wxWidgets or a smart functional integration of some Boost library features & a GUI than you'd ever have hopes of getting that code to work with anything modern or useful today. I loved OS/2. Borland had a Beautiful C++ compiler for it and CSet/2 was one of the better standards compliant compilers at the time as well. They're all bit rot by now though. Appreciate the memories but let this one die.
Online petition http://www.petitiononline.com/sombsom/