6 ms·
> 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 over
by castell 11y ago
> 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.
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 http://en.wikipedia.org/wiki/Object_Linking_and_Embedding and http://en.wikipedia.org/wiki/Compound_document http://en.wikipedia.org/wiki/Compound_document , not COM directly)
- vidoc 11y agoThe 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
- lclarkmichalek 11y agoNaive REST (HTTP, JSON) isn't exactly known for its performance
- vidoc 11y agoAgreed, that said, I'm kind of wondering what non-naive (smart?) REST is, no sarcasms :P
- bitwize 11y agoIt's called Plan 9. 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.
- lumpypua 11y agoYou 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.
- thezilch 11y agoSeems to be doing better than the speeds sited by the KDBUS thread -- https://www.techempower.com/benchmarks/#section=data-r10&test=json https://www.techempower.com/benchmarks/#section=data-r10&tes...
- lclarkmichalek 11y agoThe fact that one slow implementation is slower than another slow implementation says nothing.
- castell 11y ago> 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. More info: http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html
- anton_gogolev 11y agoApples and protocols. REST is an architectural approach, and it can very well be using the same overdesigned XML envelopes, binary-encoded payload or anything else, really.
- roel_v 11y agoYou 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).
- 72deluxe 11y agoCOM 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.
- icebraining 11y agoLibreOffice uses UNO, which is their own version of COM: http://en.wikipedia.org/wiki/Universal_Network_Objects http://en.wikipedia.org/wiki/Universal_Network_Objects
- 72deluxe 11y agoThanks! I'll take a look!
- 11y ago
- bandrami 11y agoIt'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.
- XorNot 11y agoExcept 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!
- bandrami 11y agoWe 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.
- efaref 11y agoYou 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.
- 1wd 11y agoIsn't Mozilla's XPCOM (the basis of Firefox and all Mozilla applications?) also based on COM? https://en.wikipedia.org/wiki/XPCOM https://en.wikipedia.org/wiki/XPCOM