> Since then I'm convinced that people who are inventing RPC solve non-existing problems.
Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.)
Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes.
It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. It goes without saying that binary based implementations of such Component Object Model are faster than XML based ones - a fade of the last ten years.
The component format (if you call it that way) that just works is HTML5.
You do realize that pretty much whole of Windows is, underneath, based on COM, including most of the .Net-exposed system API's?
I'll agree that COM and DCOM are... hairy, if you're implementing COM objects 'by hand'. But there's a reason for all of it, and I have yet to see an easier and more flexible way to write cross-language components. I could write a COM object in C++, call it from VBScript in a very simple command line program, as well as use it directly in a Web application in (here it comes!) 1999! That's 15 years ago! And while COM is universally reviled now, and none of the cool kids will want to be seen within 100 feet of it (actually, the 'cool kids' don't even know what COM is any more, it's so 2005 to hate on COM...), for those who spend 6 months on understanding it, it worked very well, and has been supported for close to 20 years now (on Windows, that is).
COM is indeed an interesting beast and very useful. Being able to integrate other programs into yours, relying on COM to do so is very helpful. I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). I once wrote something that processed a plethora of Word documents using Word via COM to extract data from them and shove it into a database.
I can't fully remember how I did it but I recall type libraries, including generated headers etc. but I remember being impressed by it.
And as you state, all calls within Windows rely on COM. Stop the RPC service and observe as your system becomes unusable.
"XPCOM adds a lot of code for marshalling objects between different usage contexts (e.g. different languages). This leads to code bloat in XPCOM based systems. This was one of the reasons why Apple forked KHTML to create the WebKit engine (which is now used in several web browsers in various forms, including Safari and Google Chrome) over the XPCOM-based Gecko rendering engine for their web browser.
The Gecko developers are currently trying to reduce superfluous uses of XPCOM in the Gecko layout engine. This process is commonly referred to as deCOMtamination within Mozilla."
But my original top comment was about RPC and the compound document format (OLE as example), not about COM.
"OpenDoc's flexibility came at a cost. OpenDoc components were invariably large and slow. For instance, opening a simple text editor part would often require 2 megabytes of RAM or more, whereas the same editor written as a standalone application could be as small as 32 KB. This initial overhead became less important as the number of documents open increased, since the basic cost was for shared libraries which implemented the system, but it was large compared to entry level machines of the day. Many developers felt that the extra overhead was too large, and since the operating system did not include OpenDoc capability, the memory footprint of their OpenDoc based applications appeared unacceptably large. In absolute terms, the one-time library overhead was approximately 1 megabyte of RAM, at the time half of a low-end desktop computer's entire RAM complement.
Another issue was that OpenDoc had little in common with most "real world" document formats, and so OpenDoc documents could really only be used by other OpenDoc machines. Although one would expect some effort to allow the system to export to other formats, this was often impractical because each component held its own data. For instance, it took significant effort for the system to be able to turn a text file with some pictures into a Microsoft Word document, both because the text editor had no idea what was in the embedded objects, and because the proprietary Microsoft format was undocumented and required reverse engineering.
It also appears that OpenDoc was a victim of an oversold concept, that of compound documents. Only a few specific examples are common, for instance most word processors and page layout programs include the ability to include graphics, and spreadsheets are expected to handle charts. [...]
But certainly the biggest problem with the project was that it was part of a very acrimonious competition between OpenDoc consortium members and Microsoft. The members of the OpenDoc alliance were all trying to obtain traction in a market rapidly being dominated by Microsoft Office. As the various partners all piled in their own pet technologies in hopes of making it an industry standard, OpenDoc grew increasingly unwieldy. At the same time, Microsoft used the synergy between the OS and applications divisions of the company to make it effectively mandatory that developers adopt the competing OLE technology. In order to obtain a Windows 95 compliance logo from Microsoft, one had to meet certain interoperability tests which were quite difficult to meet without adoption of OLE technology, even though the technology was largely only useful in integrating with Microsoft Office. OpenDoc was forced to create an interoperability layer in order to allow developers to even consider adoption, and this added a great technical burden to the project."
I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user (but this might be due to my lack of knowledge about those systems - I would welcome being enlightened). … I once wrote something that processed a plethora of Word documents using Word via COM to extract data from them and shove it into a database.
This is more of a ideological difference in how things should, and can, be done. For a long while, the only way to reliably edit Word documents was using Microsoft Word (half of it being undocumented, and half of it being documented as "this is supposed to do whatever Microsoft Office does"), so you effectively needed to embed Word within your program in order to reliably edit Word documents. A lot of that changed
In the open source world, there are canonical tools, but traditionally it's been about the format being open and accessible explicitly so you don't need to rely on/run a third-party program to do the manipulation, rather either roll your own manipulation routines following the documented standard (thereby strengthening the ecosystem with multiple implements, hopefully) or use a library (that the canonical tool may be based on/also use).
Both schemes have their advantages and disadvantages. It would be an interesting study in why/how the different ecosystems evolved to favor one over the other, how that has changed over time, and how that's influenced the size and robustness of the respective ecosystems. There's probably a lot of influence on the Windows/RPC side coming from the canonical tools being primarily interface GUI interfaces, which is then natural to want to "drive" or "control" remotely, vs "headless" interfaces that are able/meant to be scripted as a first order requirement.
> I don't know of a way on Linux or OSX to embed a word processor to work on documents but never show the user
KDE has KParts and GNOME has Bonobo. The latter is apparently deprecated, but it used to be used by the desktop panel for embedding widgets running in separate processes.
I believe that is currently called kparts. Both gnome and kde had corba models early on and looked to be following the OpenDoc model. I think both orbit and Mico are now orphans. They seemed to scale it all back and pivot. I think people want widgets with behavior, not full blown browsers and word processor components.
It is still working very well indeed. I was recently trying to add photos to iCloud programmatically on Windows. Guess what, there is a COM interface for that.
COM sort of works, on Windows, when when one or preferably both sides of the connecting components are made by Microsoft. You never see non-Microsoft code talking to non-Microsoft code from a different vendor via COM. This is not a successful component interface standard.
Huh? ArcGIS is wholly extendable, and complete businesses are based on the Arc extension ecosystem, using COM. AutoCAD can (could?) be extended using COM. I've personally written extendable systems using COM. COM is a hugely successful component interface standard. Name any other standard with the same speed, flexibility and adoption.
Again, I'll agree that it's not trivial to implement a COM object. You need good understanding of C(++), the Windows API, threading, and some more things. There are tools to make it easier (e.g. to write a COM object in Visual Basic) but they generally don't make for robust components. In the hands of a competent, experienced developer, COM is a massively powerful tool.
COM is: "Unlike C++, COM provides a stable ABI that does not change between compiler releases. This makes COM interfaces attractive for object-oriented C++ libraries that are to be used by clients compiled using different compiler versions." http://en.wikipedia.org/wiki/Component_Object_Model
Others are talking about the compound document format OLE. And about DCOM (Distributed Component Object Model). Both OLE 1+2 and DCOM are not that great implementation wise, in retrospect. COM on the otherside is fine.
D-Bus is like DCOM, and has similar/other deficits, as do the competition: CORBA, RMI, XML-RPC, SOAP.
MDI and compound document format were an oversold concept, that failed. Today we have HTML5 with iframes.
I've written non-microsoft code that talks to non-microsoft code via COM. It was a painful experience, but you do in fact see it happen. I also know people who do this regularly, and seemingly fairly painlessly. I wouldn't call it a standard by any measure, more of an underdocumented and arcane mechanism.
It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage.
True, but the idea of the self-registering COM object eventually seemed to limp across the finish line.
Anyways. "Two key kdbus developers" (ahem) have said that the entire kernel signal mechanism should be deprecated because it's "too brittle and complex". When I read that, a big light bulb turned on in my head about what the actual problem is here.
Signals are too brittle and complex. That's why you have to read three whole manpages to figure out what happens if a process gets the same signal twice in rapid succession.
They are also un-Unixlike: they are used to communicate three or four different kinds of information, and they do most of them badly.
Exactly. Signal mechanism makes sense to notify synchronous errors that arise from the thread's own execution, like SIGSEGV or SIGILL or SIGFPE.
Most of the rest of the traditional UNIX signals are events that should be communicated asynchronously via file descriptors that a process can poll at its leisure, which would be more UNIX-y.
Except they're not wrong. We have a potentially infinite set of signals and data we'd like to communicate to programs and a very limited set of signals to do it with. I mean apache uses sigwinch as an exit code!
We have a potentially infinite set of signals and data we'd like to communicate to programs
Ah, I think I've identified your problem.
Signals are for alerting programs to a specific (small) set of changes of external states. There's nothing "potentially infinite" there (frankly having 2 different SIGUSR's is generous).
For transmitting arbitrary messages, Linux provides message queues, which are very nearly sockets (and the ways they aren't sockets make using them for IPC easier). What's the limitation there?
It lacks multicast, sure, but then receivers can just make their own queues and have the broadcaster send to them if you want that.
You answered it yourself. It lacks efficient multicast.
What dbus really needs is an efficient kernel-level capability-aware multicast IPC mechanism, and a total rewrite of the user-space daemon to not be rubbish.
All the user-space daemon needs to do is provide a registration point for other processes to find and connect to each other via (existing) unicast or (new) multicast mechanisms.
My initial thoughts were that kdbus /was/ that IPC mechanism, but it sounds like that might not actually be true.
The problem with REST is that it's great for what it was intended to do initially, but there are too many engineers that don't take their medication that actually use it to do RPC :P
> Naive REST (HTTP, JSON) isn't exactly known for its performance
Naïve XML isn't known for its performance either. JSON is usually faster to parse than XML.
While D-COM uses a binary protocol, it uses XML for its "Introspection Data Format". Objects instances may implement Introspect which returns an XML description of the object, including its interfaces (with signals and methods), objects below it in the object path tree, and its properties. Objects may be introspected at runtime, returning an XML string that describes the object. The same XML format may be used in other contexts as well, for example as an "IDL" for generating static language bindings.
In Plan 9, each process has its own filesystem tree, and other programs can expose themselves to this process as file servers, meaning that data internal to the programs can be accessed via the same read, write, delete, etc. calls as files. For example, when running under rio, the Plan 9 window system, the current window contents are available at /dev/window and you can write draw calls to /dev/draw to do graphics.
REST is pretty much applying Plan 9 principles to the Web and http.
You can use REST architectural principles with a faster transport and serialization. For example, using a REST style API for a messagepack or thrift RPC service.
Many RPC solutions ultimately failed, because they were slow and overdesigned/complex. (e.g. CORBA, Network OLE/DCOM, Java RMI, XML-RPC/SOAP and other XML-based protocols, etc.)
Whereas e.g. REST (if you call it even RPC) is just very simple and enough for most purposes.
It's more like the concept of Component Object Model failed. For example OLE (the base technology behind DCOM) doesn't fly beside the legacy Office usage. It goes without saying that binary based implementations of such Component Object Model are faster than XML based ones - a fade of the last ten years.
The component format (if you call it that way) that just works is HTML5.
Edit: okay, it seems it's a controversial topic (My comment used examples which were DCOM and OLE 1+2 (the original MS Office thing "Compound document") - http://en.wikipedia.org/wiki/Object_Linking_and_Embedding and http://en.wikipedia.org/wiki/Compound_document , not COM directly)