Since KDE dropped CORBA completely, and is using DCOP everywhere instead, naturally the question arises why aRts isn't doing so. After all, DCOP support is in KApplication, is well-maintained, supposed to integrate greatly with libICE, and whatever else.
Since there will be (potentially) a lot of people asking whether this is really necessary, here is the answer.
First, you need to understand what exactly DCOP was written for. It was intended to be a quick-two-days hack at the KDE-TWO meeting, to have a "lightweight" communication protocol. So of course, there was no time to define a marshalling concept for instance. Or communication protocol. Instead, most of the thing bases around the Qt serialization(streaming) operator and libICE.
It is, as I see it, a hack which perfectly enables applications to send primitive messages like "open a window pointing to http://www.kde.org" or "your configuration data has changed".
However, inside aRts the focus lies on other things.
type concept |
The idea is, that little plugins in aRts will talk involving such data
structures as "midi events" and "songposition pointers" and "flow graphs".
These are complex data types, which must be sent between different objects, and be passed as streams, or parameters. With DCOP, the only way to achieve this would be to define new classes for them, supporting the Qt streaming operator. But that way, they would be inaccessible to everything but direct C++ coding. Specifically, you could not design a scripting language, that would know all types plugins may ever expose, as they are not self describing.
|
interfaces of objects |
About the same argumentation is valid for interfaces as well. DCOP objects
don't expose their relationships, inheritance hierarchies, etc. - if you
were to write an object browser which shows you "what attributes has this
object got", you'd fail.
If you have an object reference, there is no way you could figure out, which methods you could invoke on that object. This seriously breaks applications like aRtsbuilder. But remember: DCOP was intended to replace kwincom, and not CORBA or some "real middleware".
|
integration of streaming |
Why MCOP even exists is: it should work fine with streams between objects.
aRts makes heavily use of small plugins, which interconnect themselves with streams. The CORBA version of aRts had to introduce a very annoying split between "the SynthModule objects", which were the internal work modules that did do the streaming, and "the CORBA interface", which was something external. Much code cared about making interaction between "the SynthModule objects" and "the CORBA interface" look natural, but it didn't, because CORBA knew nothing at all about streams. MCOP does. Look at the code (something like simplesoundserver_impl.cc). Way better! Streams can be declared in the interface of modules, and implemented in a natural looking way.
|
speed I: protocol |
One can't deny it. One of the reasons why I wrote MCOP was speed. Here some
arguments why MCOP will definitely be faster than DCOP (even without giving
figures).
An invocation in MCOP will have a six-"long"-header. That is
Comparing this to DCOP, you'll see, that there are at least
|
speed II: connections |
In DCOP, all requests are running through a server (DCOPServer). That means, the process of a synchronous invocation looks like that:
In MCOP, the same invocation looks like that:
Say both were implemented correctly, MCOPs peer-to-peer strategy should be faster by a factor of two, than DCOPs man-in-the-middle strategy. Note however that there were of course reasons to choose the DCOP strategy, which is namely: if you have 20 applications running, and each app is talking to each app, you need 20 connections in DCOP, and 200 with MCOP. However in the multimedia case, this is not supposed to be the usual setting.
|
speed III: hard data |
I tried to compare MCOP and DCOP, doing an invocation like adding two numbers. I modified testdcop to achieve this. However, the test may not have been precise on the DCOP side. I invoked the method in the same process that did the call for DCOP, and I didn't know how to get rid of one debugging message, so I used output redirection. The test only used one object and one function, expect DCOPs results to decrease with more objects and functions, while MCOPs results should stay the same. Also, the "dcopserver" process wasn't connected to other applications, it might be that if many applications are connected, the routing performance decreases. The result I got was that while DCOP got slightly more than 2000 invocations per second, MCOP got slightly more than 8000 invocations per second. That makes a factor of 4. I know that MCOP isn't tuned to the maximum possible, yet. (Comparision: CORBA, as implemented with mico, does something between 1000 and 1500 invocations per second). If you want "harder" data, consider writing some small benchmark app for DCOP and send it to me.
|
transparency |
CORBA had the nice feature that you could use objects you implemented once, as "seperate server process", or as "library". You could use the same code to do so, and CORBA would transparently descide what to do. With DCOP, that is not really intended, and as far as I know not really possible. MCOP on the other hand should support that from the beginning. So you can run an effect inside artsd. But if you are a wave editor, you can choose to run the same effect inside your process space as well.
|
QoS, stream transfer |
Although MCOP does not currently do so, the possibilities are open to implement quality of service features. Something like "that midi event is really really important, compared to this invocation". Or something like "needs to be there in time". On the other hand, stream transfer can be integrated in the MCOP protocol nicely, and combined with QoS stuff. Given that the protocol may be changed, MCOP stream transfer should not really get slower than conventional TCP streaming, but: it will be easier and more consistent to use.
|
MCOP doesn't use Qt |
There is no need to base a middleware for multimedia on Qt. Deciding so, and using all that nice Qt-streaming and stuff, will easily lead to the middleware becoming a Qt-only (or rather KDE-only) thing. I mean: as soon as I'll see the Gnomes using DCOP, too, or somthing like that, I am certainly proven wrong. Well, whatever. aRts was always intended to work with or without KDE, with or without Qt, with or without X11, and maybe even with or without Linux (and I have even no problems with people who port it on popular non-free operating systems). It is my position that non-GUI-components should be written non-GUI-dependant, to make sharing those among wider amounts of developers (and users) possible.
|
I see that using two IPC protocols may cause inconveniences. Even more, if they are both non-standard. However, for the reasons given above, switching to DCOP is no option. If there is significant interest to find a way to unite the two, okay, we can try. We could even try to make MCOP speak IIOP, then we'd have a CORBA ORB ;).
My favourite two solutions would be:
However, it may not be the worst possibility to use each protocol for everything it was intended for (there are some big differences in the design goals), and don't try to merge them into one.