Waldo Bastian talks about KDE's involvement in freedesktop.org as part of a larger interview with several major players of the interoperability and common infrastructure movement. Waldo knocks down certain myths and covers everything from accessibility to the DCOP-inspired D-BUS.
Dot Categories:
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. :) )
-panzi
Check out the D-BUS tutorial first: http://www.freedesktop.org/software/dbus/doc/dbus-tutorial.html
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.
Okay, I'm sporry, i guess I was misinformed.
I thought D-BUS was set to be adopted by GNOME in the near future and had no idea that it was actually absed on DCOP and that it is better.
In that case, i think adopting it for KDE 4 would be a GREAT idea and probably drive GNOME to adopt it and so our desktop unification woes would be mitigated.
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.
It won't change anything for KDE. Instead of DCOP using libice as the transport protocol, it can use D-BUS. DCOP will still be around it will just use D-BUS underneath.
And yes, this is *exactly* what D-BUS was *designed* for. It's not GNOME-technology. Almost none of the GNOME apps use it in fact. GNOME uses CORBA.
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..
struct Triangle
{
QPoint p1, p2, p3;
};
inline const char* dcopTypeName(const struct Triangle& triangle)
{
return "QPoint,QPoint,QPoint";
}
inline QDataStream& operator<<(QDataStream& str, const Triangle& tri)
{
str<
Please be sure to bring up your concerns on the right freedesktop.org forums! They are very willing to fix issues with D-BUS, but if you don't tell them it will never happen.
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).
Don't try to use a horse for travelling the sea!
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.
>>The normal Windows RPC mechanisms are COM, DCOM, and MSRPC.<<
For old applications. They are all deprecated in .Net and Longhorn.
>>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.
But a) they still have the same interface, the serialization is transparent and b) today's Remoting will be deprecated in favour of Indigo / System.MessageBus.
> a) they still have the same interface, the serialization is transparent
And since it's transparent, the natural conclusion is that one should use
the most efficient serialization, as doing otherwise does not give any
advantage.
> b) today's Remoting will be deprecated in favour of Indigo / System.MessageBus.
Yeah, I'm sure they can continue throwing out new APIs in 2-year intervals
for the next 20 years, no doubt.
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!
"When I'm asking simple questions, and getting simple answers, I'm talking to God." -- Einstein
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...
/David
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. :-(
So you have never used konqueror, of course you can copy/paste URL's.
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.
Have you filed a bug report? I believe most developers use middle-mouse-button copy/paste, so this bug could be overlooked for quite a while if you don't report it.
No, I haven't - I should have done earlier. However now is not really the time to be filing reports against 3.1.4.
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.
ack. I'm sorrt, but he's right. I've been using nothing but konqueror for two years and copy/paste support is terrible (though I do love the "clear location bar" button dearly).
I rely almost entirely on my mouse's middle button, because you never know what that last thing you actually managed to copy to the clipboard was.
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.
Does KDE's Klipper copy to a differnt place then XFree86 does?
It's all configurabel in Klipper. The default are different clippboards for X
and ctrl- . Why I can't tell you, and I have never had any problems cutting and pasting :-)
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.
So there is actually a move to unify the desktop on Linux.
When all apps can integrate regardless of GUI toolkit used,
then it won't matter which a developer chooses. Great.
Great mess.
Something for KDE to include? Or is there something similar available already?
Seems that GNOME is getting ahead of KDE in several areas: integration, information managment etc.
Well, it's maby time for me to also lend KDE a hand (or two). Where do I start?
Comments anyone?
For something like Expocity I would for starters take a look at the advanced pager. My guess is there are some/lots of code to steal/reuse to get you started. Good luck!
in which ways is GNOME ahead of KDE in integration and information management?
Their web browser context menus have "View Document Source" in them? :-)
Epiphany does? that's news to me =)
You could easily make a KonqMenuPlugin to add said action, if you wanted to, and distribute it. =)
> You could easily make a KonqMenuPlugin to add said action, if you wanted to, and distribute it. =)
No offense, but that's the dumbest thing I've ever heard. =)
> No offense, but that's the dumbest thing I've ever heard. =)
I'm sure it would appear dumb to people who beleive viewing source is a feature appreciated by very many intermediate users =)
Mozilla, Opera and IE think it's important enough. Is the KDE approach to make things annoying and to push users to other browsers?
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!
> 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?