Comments

Waldo's comments suggest that by KDE4 we will see the KDE Project making a committment to migrate from DCOP to D-BUS. Is this policy, or his opinion?

From what I have read of the two technologies, and largely based on the integration opportunities, I think this sounds like a good idea, but I know it has been a topic of some controversy since it was first raised.

It's true he does say that it would be a good idea to switch to D-BUS by KDE 4, however he is one of the few KDE developers who endorses such a move. Don't be suprised if this doesen't happen.

D-BUS is nice, but how is it really better than DCOP and why should KDE switch to D-BUS instead of the rest switching to DCOP? In addition, such a major change would definitely set KDE development back a few months while GNOME would be speeding ahead since they already use D-BUS.

I am all for integration, but such a move, while a win for the Linux desktop it also seems like a big blow to the hard work that went into DCOP and in making DCOP work through out KDE. It also uses up precious time.

BTW: I hope KDE 3.3 will have a release cycle no longer than 6 months since KDE 4 will need a lot of time, probably at least a year and a half.

Is D-BUS based on DCOP? if so I'd hope a switch
wouldn't be as radical as you are suggesting.

Gnome has it's own DCOP-ish "cobra" so they will
be just hard at work kitting together their already
loosely knit applications anyway with this new
framework. on the other hand, though we shouldn't
worry about gnome innovationg faster than us, rather
we work together with them.

It'd be REALLY cool if DCOP didn't have mad-style KDE
dependencies so gnomes could use it without hainvg to
install KDE as well.

1) Yes, D-BUS is based on DCOP. Its actually very DCOP-ish, and was designed so it could replace DCOP. Its got the advantage that its desktop-agnostic, unlike DCOP.

2) GNOME uses CORBA, a major cross platform standard for IPC. Switching to DBUS would be even a bigger pain for them, because CORBA is *very* different from D-BUS, while DCOP isn't that different from DCOP.

So we could speak of D-BUS as a DE-intependent DCOP successor? Dose it deliver other improvements than this? I heared it's faster then CORBAS IPC, is it faster than DCOP? Or are there no other differences? (I konw, my questions are annoying. :) )

Choice quote: "Semantics are similar to the existing DCOP system, allowing KDE to adopt it more easily."

Overall, D-BUS is more elaborate and has more features than DCOP.

Supposedly, Havoc has said that its actually harder for the GNOME people to adopt it, because its so similar to DCOP.

Overall, I think D-BUS is a good thing, but whether it actually gets into KDE 4 is up to the KDE dvelopers. Its good that they are wary about this, though. KDE is clearly the better framework, at least in places like DCOP, KParts, KIO, and Qt, and I would really hate to see better technology get pushed aside in favor of easier to integrate technology.

D-BUS is better than DCOP because it has a chance to become a desktop-independent (and even GUI-independent) standard. As I understand it DCOP has dependencies on QT and X windows, while D-BUS does not, making it much more likely to be adopted as a standard. D-BUS would be good for the Linux desktop, and whatever is good for the Linux desktop is good for KDE. I doubt that it would take that much effort to switch over anyway, because D-BUS is supposed to be similar to DCOP.

in addition to what others have mentioned, DBUS will allow marshalling w/out relying on Qt's idea of data ordering, which means it can be used by all sorts of apps. think about controlling apache via a DBUS control: fire up kdcop (kdbus? ;) and click on the "apache -> restart" item and voila, apache restarts.

DBUS is also being designed with the idea that it can be used (and authenticated) over the network, something that's clumsy at best with DCOP...

DBUS is really something of a more globally useful and flexible version of DCOP. since KDE is already centered around using DCOP and nothing else is, this transition should be easier for KDE than most others. the big thing for KDE will be providing a compat layer so that apps speaking DCOP (e.g. KDE2/KDE3 apps) will be able to talk to apps using DBUS. this should be doable with some work and if done completely should make the transition practically transparent. but that part of the puzzle is yet to even really be looked at AFAIK...

IMO it basically boils down to the idea that we've learned a lot about how well DCOP works via it's use in KDE, as well as where it's weak. DBUS is attempting to address the weaknesses and create something that allows the rest of the world to take advantage of what we've learned as well... everyone will win in the end...

Ouch, if I hear it one more time, I'll scream. Qt's marshalling is trivial to reproduce. See dcopc, see the Qt source code, etc. (Yes, there is an issue of fixing a format revision. But it's addressable, it's in fact /trivial/ to address, compared to the 'translation layer' idea which may not be even doable, given very different effective type equivalence semantics, and DCOP's natural uses on untagged marshalling)

To be more specific, here is an example where DCOP and D-Bus semantics diverge on type equivalence, making fully transparent conversion impossible[1]. Is this construction useful? I am not sure, but it can provide fully transparent overloads in an arbitrary number of combinations (imagine a function that should take 3 of the Triangles below -- doing it like this lets you take any of them as 3 point). Is it a big hack? Perhaps. But "no one will use stuff like this" is often famous last words..

If its so trival why is dcopc so broken beyond repair to the point its disabled? Ill give you a hint, its not ;)

DBUS may not fix the problem completely, but it will give us a common ground to speak on. That and its more code we dont need to maintain. Unless you are offering to maintain libice for us. The only pisser will be that the GNOMES are too attached to their CORBA to even consider something better. In the end I fear even if we use DBUS we will never see the interop that is promised.

dcopc is probably broken because no one has actually wanted to use it, and that probably happened because it was not promoted. People did not go around shouting from every tree how it's a solution to every problem in the world, how it's something revolutionary, and how KDE and Gnome would both be using it before developers have even heard of it.

And look, I've written marshalling code dozens of times (quite a bit this week, in fact). At its most complicate it is just a bunch of bit shifts and masks, and some of the most boring and trivial code that's out there[1]. The only piece of Qt marshalling that's complicated is for QImage, which basically just sends a PNG over the wire --- but it's hardly critical, and any decent toolkit framework can load and save PNGs. And there is nothing particularly magic about writing out an integer as 4 bytes in a fixed-endian order, and a point as 2 such integers.

And as to maintaining libICE: I wouldn't maintain it, but I would gladly maintain a proper implementation of the wire protocol; including writing it, which is probably at most about a week long excercise for the core protocol. (I can't comment on the authenication protocol plugins, since they are not specified in the core spec; however magic cookies can't be too hard).
A flip question, however: would you maintain the current implementation of dbus (I certainly wouldn't)? Remember, maintainers don't stick with projects forever.

[1] Although DBus and ICE both make it more 'fun' by introducing some gratious byte-swapping

Yeah, but in the end DBUS is also just repeating what SOAP did in the last years. They re-invented their own serialization format (instead of XML or one of the binary XML formats for the performance-junkies), re-invented an interface description language (IDL vs WSDL/Xml Schema) and half-re-invented authentication mechanisms (as they are using SASL). In the future, if DBUS should become more popular and is used over the network, they will probably re-invent encryption mechanisms, maybe transaction and routing mechanisms and so on. Great plan.

And they are also doomed to re-invent new IDLs for all applications that already have a SOAP-equivalent.

no, it isn't just repeating what SOAP or XMLRPC has done. it doesn't use XML, which means its faster, simpler and lower overhead. it's primary use will be applications on the same machine running as the same user. you are right in that DCOP, DBUS, SOAP and XMPLRPC are remote procedure call schemes, but DCOP and DBUS are designed specifically with desktop use in mind. the tasks and needs there are rather different from (and in some ways a lot simpler than) web services. DCOP works very well with just a few outstanding issues, which hopefully DBUS will allow us to address.

as for reinventing encryption and authentication: it would not only be more work to reinvent than use what already exist; it would also limit interop and be a pain in the patoot to verify it as being Correct compared to leveraging something that's already been through the usual cryptographic scrutiny.

the direction you seem to be leaning towards (a high-overhead, complex, and overly-complete solution) is very similar to what drove people to try CORBA. both KDE and GNOME have attempted to use CORBA. but that real world usage revealed that a simple, lightweight, purpose-built mechanism beats the shinola out of hacking heavy, general purpose mechanisms for desktop IPC.

1. I don't think that there is any significant performance difference if you are using a binary XML serialization.
2. SOAP is *not* limited to web services. That's just its marketing niche. SOAP is also used in embedded devices (like all UPnP devices) and on Windows for IPC. Another myth is that SOAP is limited to HTTP. Unlike XMLRPC it isnt. .Net allows other mechanisms like raw TCP for faster communication.
3. SOAP is not as complicated as CORBA, it is a really simple system. All you need are four XML tags. There are extensions on top of SOAP that are needed in some cases, but DBUS will have the same problem if it should ever do more than trivial messaging

1. Binary XML is just for faster over-the-wire transfer. At the other end
XML still needs to be parsed which is very costly compared to DBUS/DCOP marshalling.

2. Yes, but it was primarily design with web services in mind.

SOAP had specific design goals, features and limitations. Don't try
to use it for something it was not meant to do (inter-desktop
communication) even thought it is the standard in IT'S domain (web
services).

SOAP can be used on Windows for IPC, but isn't generally. The normal Windows RPC mechanisms are COM, DCOM, and MSRPC. MS's RPC tends to use the DCE RPC NDR format for serializing the data, and is generally pretty complex. There are historic reasons for all of this, but it's not important right now.

I would hope that D-Bus is sufficient that a SOAP connector could be developed, just as an XML-RPC connector was developed for DCOP. The problem with taking a standard and adding proprietary extensions to it that become required by your implementation is that it nullifies the advantage of using the standard in the first place. For KDE and Gnome, there's no marketing department that will trumpet the use of something like SOAP despite the fact it's dependant on those proprietary extensions, so there's no point in using it.

>>For KDE and Gnome, there's no marketing department that will trumpet the use of something like SOAP despite the fact it's dependant on those proprietary extensions, so there's no point in using it.<<

I'd call DBUS proprietary as well. The protocol is published, but instead of using the standard that the W3C established a completely new protocol has been created. It's like re-creating HTML, no less.

In .NET, the serialization format can be specified by implementing the

System.Runtime.Remoting.Messaging.IRemotingFormatter

interface. There are two already provided, BinaryFormatter and SoapFormatter.
The former is preferred for high-performance needs, because the serialization
and deserialization is much faster and the transferred data is more compact
than for SOAP. Of course, the same argument applies to DBUS.

For web services, different trade-offs are possible, because performance
and interoperability considerations are radically different from IPC.

SOAP is hardly simple; it is a classic example of "design-by-committee" at its worst, and consists entirely of bloat that is unneccessary in the problem space DBUS is addressing. I'd argue that the SOAP-Bloat is unneccessary in *any* problem space -- SOAP adds a lot of overhead without providing very much (if any) added value.

Your "four tags" quadruple the size of most SOAP messages. I also disagree that DBUS will encounter the "same problem" of bloat that SOAP suffers from; I've been involved in a number of projects that used REST and simple XML messages /without/ SOAP wrappers and SOAP bloat. What the designers of SOAP forgot is that all of the magic happens in the WSDL, not in the RPC wrapper. If you absolutely feel the need to wrap your messages up in a bunch text, use XML-RPC. The specification is all of two pages (compared to the 20 pages of SOAP crap you have to wade through).

DBUS seems to be fairly light, like DCOP, which is nice. Distrust overly complicated system!

I want to use the Einstein quote "when I'm asking simple questions and getting simple answers, I'm talking to God" in a paper I'm writing for school, and I'd like to know more about where exactly this quote comes from. Any information on when and where Einstein said this? Response much appreciated.

It's nice with what the freedesktop.org is trying to do. I just hope that somebody is trying to adress the very bad behavior of copy/cut & paste through all linux applications, even though it works most of the time in KDE it's a pain from other applications in my experience. I think that you should be able to use ctrl+c/x and then do ctrl+v through all applications...

If fact, just selecting should be enough (it is Unix after all, not Windows...). I have noticed that Konqueror/KHTML is about the worst application of all when it comes to copy/pasting. It hardly ever works, and most of the time it's faster to just re-type an URL than to try and copy/paste it. :-(

And you have that icon on the left of the URL sou you can delete the old URL and then click the central button and you have it or you can use the Knotes or you can ...

About DBUS , there is a lot of really good apps from the other part of the universe : mozilla, openoffice, gabber, ... so it is a must a better integration just because kde is really the best but those wondefull apps from the dark side of the moon jai,jai, :-)

No, I'm afraid he's right. At least on my system, selecting some text in Konqueror (3.1.4) and then pressing Ctrl+C doesn't always copy properly. It's very irritating, but because the 3.2 release is so close I've put up with it.

Yes, I know you _can_. Konqueror is my main browser, I only switch to Mozilla if a site really doesn't work on Konqueror. However, I still frequently run into this problem that copy/pasting text from a webpage doesn't allways work. I see that on both my laptop and my desktop systems.

What I've never understood is why there seems to be two different clipboards. If I copy by selecting (classic X method) I can paste with the middle mouse button but if I copy or cut using ctrl-c or ctrl-x I have to paste using ctrl-v.

The clipboards are different because they are used in different ways. With a Windows-style clipboard, you can copy a URL with Ctrl-C, select all the text in the location bar, delete it with backspace, and Ctrl-V to paste the URL. If the clipboards are unified, selecting anything nukes the clipboard, so when you paste you just paste back what you selected. This was a very *very* common source of complaints in KDE 2. (Yes I know about the button to clear out the location bar, but some people are used to doing it the other way, and there are other situations where separate clipboards are useful).

Related question: when will kde programs start using the systray specifiation from freedesktop.org? It's rather frustrating that the systray icons of most GTK+ apps (like Gaim, Rhythmbox) also work fine in KDE, but most KDE's systray icons (kopete, k3b, printing icon) all appear in a seperate window in Gnome.

Given that there are KDE apps which don't use KSystemTray class directly, but use the low level API for systray (they were simply written before KSystemTray was created AFAIK), hardly before KDE4, as the low level API can't handle the way fd.o systray spec works. And given that there are certain plans to (quite radically) change the way KDE systray works (the underlying mechanism) to something better, maybe never.

Just because some specification is posted at fd.o doesn't necessarily mean that everybody is suddenly going to use it. See for example the "extension to the ICCCM selections mechanism" (nobody uses that at the present time), or XDS (neither GNOME nor KDE use it, although there are some apps which use this one). Maybe these proposals will get into use eventually, maybe they'll silently die, maybe they'll be superseded by something better, who knows?

That said, I think it shouldn't be that difficult to write a small utility that you'd run with GNOME, which would act like a proxy and make KDE apps appear like using fd.o systray spec to outside. So the answer to your 'when' could be 'when somebody writes this'. Maybe I'll give it a try.

> A context menu should let me do interesting things in the context. Easily. It's ridiculous that when I right click on an Image, I have to go to the "Image->" submenu to do anything with it!

This was fixed.

> Is the KDE approach to make things annoying and to push users to other browsers?

No, the KDE approach is to make it so that the largest amount of end users feel comfortable in KDE. This means that we should target intermediate users (not beginning OR advanced users). This allows beginning users to get a feel for the interface quickly and advance to the intermediate stage (because nobody wants to be a beginner for long). Eventually advanced users will appreciate things too.

This is why view source doesn't belong in the context menus, and why it was a mistake re-adding it in. If you really want such advanced features, as I said, why not make a web developers plugin for konqueror?