“It just might be possible for Linux desktop users to get one of OS/2’s best features: SOM (System Object Model). Of course, many of you are asking, ‘SOM, What’s the heck is SOM?’ I’ll tell you. It’s a CORBA object-oriented shared library. Those of you who aren’t programmers are doubtlessly staring cross-eyed at the screen right about now. For you: SOM is an easy-to-use universal programming library that both KDE and GNOME developers could use to create programs that would work in any Linux desktop environment.”
This *is* a good idea: lobbying IBM for the release of something that they could release, that is still technically relevant, and that is probably in their interests to release.
If Gnome and KDE were going to get a common object model shouldn’t it be XPCOM from Mozilla? But XPCOM has been freely available for ten years now and neither Gnome nor KDE have picked it up. Instead we get object model bridges. Why would things be any different with IBM’s SOM?
XPCOM and Xulrunner is a path to off-line web apps.
Isn’t there a similar project on freedesktop.org that aims to create a abstraction layer for common dialoges based on D-BUS?
And D-BUS is a much better choice for IPC then CORBA. It’s a lot easier, it is already used by GNOME and KDE(4)/Qt4, there are bindings for a lot of languages and even the kernel uses it.
For real? A new one-size-fits-all?
I doubt this is going to be any useful. At least before someone convinces majority of KDE and GNOME core and application developers to move to something entierly new (ok, similar but yet unknown).
Wasn’t Corba so horrible KDE created DCOP (and now DBUS is partly designed after it)? And Gnome, which officially supported it, barely used it so they jumped on the DBUS car as soon as it got kind’a usable?
If my memory serves me right, CORBA already proved to be incapable of serving the free desktop – the Wikipedia page kind’a confirms that, talking about it’s design- and implementation flaws.
Google brings you to a few pages:
http://lists.freedesktop.org/archives/dbus/2005-January/002007.html
(read further on that page for reasons why Corba failed).
And the D-BUS faq talks about CORBA and other alternatives as well:
http://dbus.freedesktop.org/doc/dbus-faq.html
From what I’ve read, CORBA might theoretically be great – but in real life, it sucked for both KDE and Gnome. DBUS on the other hand already proved to be a good solution – KDE seems happy with it, Gnome as well.
I don’t know much technical details, so I’d love if someone who does can elaborate a bit more…
Gnome did this, and it became derelict.
http://developer.gnome.org/doc/whitepapers/ORBit/framework.html
Btw, this was the to result on google for ‘gnome cobra’. Perhaps next time you think of a brilliant idea, you should google for it first.
Note to self: RTFA before posting critical comments. Bah. Mod parent down.
Systems like SOM, Windows COM, Apple’s pre-OS X “Publish and Subscribe”, etc have been around for *ages*.
It was one of the foundations of NextSTEP, which is where most modern implementations get their inspiration from.
The idea has been around since the late 1960’s. The Wikipedia article on “Software Componentry” has a brief history.
For those of you who don’t realise that Linux has such a system, what do you think GNOME originally stood for? (Hint: Wikipedia knows.)
This might have made a difference about four or five years ago. But now D-Bus nicely fills the niche of the object-oriented message framework. And it does it surprisingly well; KDE and Gnome both use D-Bus now, and there is incentive to increase interoperability between the two desktops and toolkits.
Porting of SOM, WPS can’t help to Linux. This makes damage to eComStation market only. OS/2 village — http://en.ecomstation.ru/showarticle.php?id=148
As part of IBM’s Workplace OS initiative, SOM was available on their four main operating systems but unfortunately, was mostly unused.
It had nothing to do with complexity but that most development was not done in a language that would handle it properly. Maybe obviously, object handling should be done with object-oriented languages and generally on IBM, that meant Smalltalk, which wasn’t available on all systems. So, most systems got partial access to SOM and it went downhill quickly.
If SOM were used across major operating systems, it would be quite useful, but that requires cooperation that isn’t likely to happen, even in the Linux world.
…with more data, since I have the SOM code here at the bit ranch:
>>As a practical example, imagine that someone created a C++ library that was the answer to all IMAP needs. A developer couldn’t access that library from Python, unless she wrote custom code from scratch. And that wouldn’t help a developer who uses Java. With SOM, the library would be available no matter which language you chose.<<
More:
http://advice.cio.com/esther_schindler/a_little_som_thing
I’m sure SOM is great and all, but object frameworks like this have been tried and are in use on Linux. There’s a reason we don’t all use one.
On the GNOME side you have corba/orbit/bonobo for IPC and embedding. For KDE you have DCOP and kparts. And GNUstep still has its own NeXT-style object system. DBUS is set to step into a set of DCOPs functionality, which is good, but it isn’t for embedding or dynamic stuff like that, and I believe it replaces a subset of the gnome stack as well.
So why isn’t there a universal object library like SOM in Linux? It’s not just because it’s a bad idea, but it’s a question of herding cats. Having a well designed and complete one might be nice but the probability is that few would use it. Even if it were widely adopted many would still not use it; can you imagine Enlightenment or GNUstep changing their practices?
Like it or not there is no “silver bullet” for Desktop Linux.
Probably the most promising options we can explore, apart from fd.o-style cooperation (which incidentally is where most of the *useful* advances have come from lately) are the effort to make QT use the GTK main loop and an X extension for sharing theme/color data in a neutral fashion.
There is unlikely to ever be a unified desktop Linux API. The best thing we can do is to try and make it not matter which APIs you use.
Sadly the comparison to CORBA badly misrepresents SOM.
SOM was the best component model in its day, and in many ways may still be. In addition to OS/2, it formed a fundamental part of Taligent, Pink, and even Apple’s Copland, and was the basis of OpenDoc. But like many good technologies, it seemed to just fade away.
I wouldn’t write it off just yet.
Edited 2008-02-13 16:49 UTC