Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

KDE Traffic #16 For 29 Jun 2001

Editor: Aaron J. Seigo

By Aaron J. Seigo  and  Rob Kaper

Table Of Contents


Welcome to KC KDE! LinuxTag is being held this week in Stuttgart and several of the KDE hackers will be in attendance. Several groups working on various projects in KDE will meeting there to discuss the future directions of their efforts and perhaps to even get some hacking done. It will be most interesting to see what comes out of this multi-day geek fest in the weeks to come.

In this week's issue we continue to follow the stabilizing of the 2.2 series as well as some previews of 2.3 developments that are in the works just waiting for CVS to become unfrozen again.

As a new feature, starting with this issue of KC KDE we will be covering in the introduction Ralf Nolden's "KDE CVS Geek of the Week". This week's geek was (*drum roll*): Ellis Whitehead for adding support to KWin to be able to take screenshots using the Print Screen key. Karol "Gallium" Szwed was also in the running for his tooltip filter patch for KWin decorations, but he declined the honor with humility.

1. KDE FTP Support and Proxies

19 Jun 2001 - 21 Jun 2001 (15 posts) Archive Link: "Download Dialog - immortal?!?"

Summary By Aaron J. Seigo

Topics: Konqueror, Bug Tracking

People: Nils HollandMatthias Welwarsky

One of the worst kind of bugs is the kind that some users can reproduce some of the time and the rest can't reproduce ever. One such problem with Konqueror's FTP support and proxies was noted in an email from Nils Holland where he described his problem this way:

When I'm in konqueror and download some large file (say, 5 MB or more) then the dialog that shows the download's progress does not go away once the download is complete. With smaller files, it seems to work, but with big ones, it happens in about 70% of the cases that the dialog doesn't go away.

Some information that might be of relevance: I'm using a proxy server (SQUID 2.4-STABLE1) that runs on one of my machines. The SQUID-machine has a 56k modem-connection to the Internet, and the other machines which do the actual downloads and encounter the above problem acess the SQUID proxy via my internal Ethernet. In other words: I don't know if the fact that a proxy server is being used triggers the problem or has any influence on it.

As I am writing this eMail, the problem has just happened again when downloading the 8.7 MB large distribution tarball of binutils-2.11.1 from

Many others reported similar experiences, while some reported never seeing this problem at all even though they were using the same version of KDE. After some head scratching Matthias Welwarsky solved the mystery explaining, "FTP has a control connection and a data connection. During a data transfer, the control connection is idle. If it's idle longer than the timeout of the connection table on the gateway, the entry will be removed. The connection is now dead, it cannot be used any more. That is: the server cannot send the final message to the client and thus the client never completes. So, you have to work around this." Matthias also provided a detailed work-around for the problem in a later email and posted a preliminary patch to implement it. Nils reported some greater success with the patch than without but noted that there was still the occasional problem. At least it is being worked on now!

2. SOAP and DCOP

21 Jun 2001 - 23 Jun 2001 (30 posts) Archive Link: "SOAP <-> DCOP"

Summary By Rob Kaper

Topics: DCOP, Performance

People: Rik HemsleyDan PiloneMartijn KlingensDavid FaureChristian GebauerKurt GranrothAndreas PourMike Pilone

Rik Hemsley asked on kde-core-devel: "Has anyone thought of gluing DCOP and SOAP together ?" . Andreas Pour mentioned developers could take a look at EasySoap++ for such an effort, but none of the developers seemed to have worked on a DCOP/SOAP combination yet, until Dan Pilone posted:

Acutally, there is some work going on. KDE-Pim work has spawned a few of us off into basic distributed apps (Mike Pilone, Bryan Dumm, myself). We're using SOAP to do the communication between the client (KDE App) and the server (whatever, but currently either EJBs or Perl). We have talked about extending DCOP to do this SOAP communication but haven't acutally done it yet. The reason is that SOAP doesn't "quite" line up with what DCOP is doing now. Meaning, we could do a lot of what DCOP does, but not quite all of it. (The two way registration, the interface discovery, etc.) We could let the actual calls be carried via soap though. And as Kurt/Waldo pointed out, DCOP is currently using libICE as its transport. We'd need to put an HTTP transport in there, which would make security an issue again. We may end up going the route of kxmlrpcd, where there is a seperate daemon running that talks to the dcopserver. We haven't worked that out yet.

Apparently Rik Hemsley already did more work than his first post revealed, because he later mentioned:

Actually, after I'd got quite far into reading and implementing the SOAP specs I realised that SOAP is basically just an extended version of XMLRPC. I then looked at your kxmlrpc code and saw it was very similar to my own :)

Were you thinking of doing a SOAP client library as well? As in DCOP to SOAP, not just SOAP to DCOP?

Yes. I've written a class that parses a SOAP envelope and gives you the parameters you need to make a DCOP call. Right now I can send use a SOAP message to set my kdesktop background :) Next I'll do the necessary stuff for doing the reverse.

I don't know if anyone has a use for this stuff yet, because the SOAP spec still needs some work. Perhaps people are using it ? I don't know.

Anyway, I'll finish the implementation and we can announce it. It will be good PR if nothing else :)

BTW, having read all the docs and written some implementation, I've decided that SOAP is a great protocol :)

This caused Martijn Klingens to ask: "Can it (technically) replace e.g. DCOP in KDE 3?" . David Faure responded: "Yeah, sure, replace those short, binary-encoded messages, with long xml-formatted messages over HTTP. Definitely a win for performance (and security) :)" . This concern was shared by Kurt Granroth and research by Christian Gebauer confirmed the performance issues:

As the others allready pointed out, that wouldn't be a good idea because of performance problems. I just did a presentation about SOAP at the university and according to my research SOAP (and other XML-based protocols) is about 10 times slower than traditional binary RPC/RMI protocols and about 100 times slower than a raw socket connection. This paper compares SOAP with Java RMI and has a lot of detailed data:

This is the reason why Microsoft .NET uses a binary protocol for LANs and SOAP only for the internet.

While it doesn't look like SOAP will replace DCOP, it is good see some efforts to provide the necessary bindings and bridges that could increase interoperability between computer systems running different flavors of software.

3. Konqueror and Security

22 Jun 2001 - 23 Jun 2001 (5 posts) Subject: "Security issue in Konqueror"

Summary By Aaron J. Seigo

Topics: Konqueror, Security, KIO

People: Igor GilitschenskiGeorge StaikosDawit Al

Security is an extremely important issue when using a network you share with other untrusted or unknown sources, such as the Internet. A desktop system like KDE needs to keep this in mind when implementing security sensitive features such as SSL support in the web browser which many are now using for online transactions and banking. Igor Gilitschenski pointed out a serious flaw in the current SSL implementation in Konqueror saying, " A co-worker of mine pointed my attention at a possible Security problem in Konqueror today. While connecting to a i.e. Self-certified SSL site, you don't recieve a warning. You surely question, what the problem about this is. The point is the following: This makes an eventual man in the Middle attack possbile." Igor went on to detail how such an attack could successfully be made. George Staikos confirmed this was a problem and one that he was aware of. When asked what the solution was George said, "Porting kio_http to TCPSlaveBase and filling in an unfinished if() {} clause should fix it. I guess if someone wanted to, they could migrate the missing code into kio_http too. I don't know how well that will work though."

While it is probably important for those using Konqueror to be aware of the issues, its even more important that these issues get fixed. On a positive note Dawit Alemayehu has posted a preliminary patch for review that ports kio_http to TCPSlaveBase. This patch also provides several nice side benefits and will most probably be covered in detail in KC KDE Issue #17.

4. Competing Monopoly Games

24 Jun 2001 (4 posts) Archive Link: "[Kde-games-devel] Capitalist v0.1"

Summary By Aaron J. Seigo

Topics: KDE-Games, Merging

People: Daniel HermannRob Kaper

Exactly one week after Rob Kaper announced KMonop 0.1 on the kde-games-devel list, Daniel Hermann announced his KDE Monopoly game saying: " I'd like to announce Capitalist v0.1, a new Monopoly(R)-like board game for Linux. It's a server-client multiplayer game intended to be played over network. The client is written for KDE2.x. Have a look at for some screenshots and for download of the sources. "

Of course, KMonop is also has a server behind it. Concern was expressed over not only duplication of effort but also that it might confuse users trying to use the wrong client/server combination if they are both part of KDE. Both projects were started around 1998-99 so it isn't easy to claim one as being older and therefore as having precedent. Fortunately, discussion was started between the projects with the goal of merging the communications protocol used in the two projects into one single specification. The most probably solution at this point seems to be standardizing on the KMonop protocol since as Rob Kaper pointed out, " there are already two clients working with monopd (soon to be three, a Java applet client is in the works), I am of course quite biased and would like to keep monopd. Partially because it was designed and intended to support a wide range of clients, something which your protocol (if I understood correctly) was not."

So it seems that KDE will have in short order two very playable Monopoly-type games and that they should also be interoperable not only with each other, but with gtk+ and Java versions as well.

5. CVS Gets Easy: The Cervisia KPart

24 Jun 2001 - 25 Jun 2001 (13 posts) Archive Link: "Cervisia"

Summary By Aaron J. Seigo

Topics: CVS

People: Bernd GehrmannIan Reinhart GeiserRichard Moore

If you do development using CVS and use the KDE desktop chances are good that you have seen or tried Cervisia, the graphical CVS client maintained by Bernd Gehrmann. Bernd posted an announcement to the core development list saying:

I want to suggest to import cervisia into the KDE CVS, mainly for two reasons: First, I have no time to do any major work on it myself. In the last months, I have mainly acted as a 'filter' for patches others have written. As I'm not very fast in giving feedback and commiting I'm afraid this causes too much frustration for contributors. Second, many people have asked for converting this to a KPart, so it can be used in other applications (quanta e.g.). I don't have the time to do this, but when the source code is easily available via cvs, I'm confident that this can get the ball rolling. Rich has already converted the whole user interface to xmlgui.

To avoid any misunderstanding, let me emphasize that I'm not talking about a half-finished project :-) It's stable, pretty complete and polished, and it even has a non-negli- gible amount of documentation.

It was recommended by various developers to import it into the development CVS module of KDE (kdesdk) following the 2.2 release. Ian Reinhart Geiser also volunteered some coding time saying, "As one who has grown to find Cervisia very useful, I would be willing to help take up maintanece and convert it to a part. I am in the process of converting a few of my projects into parts so they can be used with KDevelop." Richard Moore replied saying that he too was already working on making Cervisia a kpart for use in both Konqueror and KDevelop. It seems that this was a much desired development, and so as with most things that enough people want in the KDE world of development it soon appeared. Richard announced his success and posted a screenshot at When asked if it was already in CVS for download Richard replied, " Not yet, I only got it working an hour ago! I'll send a patch off to Bernd (the Cervisia maintainer) as soon I've tidied up the remaining issues (the config handling needs to change now it's a part amongst other details). Assuming his email doesn't break again it should be on cervisia's sourceforge cvs a day or so later. Once KDE 2.2 is released cervisia will move into the main cvs repository, so the turn-around time for changes should be better."

6. New Konqueror Service: Printer Manager

26 Jun 2001 (10 posts) Archive Link: "Integration of print management in Konqueror (step 2)"

Summary By Aaron J. Seigo

Topics: Konqueror, Printing

People: Michael Goffioul

A preview of the new printer manager capabilities that should make it in to 2.3 was unveiled when Michael Goffioul posted:

After starting the development of a kio_print ioslave (for print system browsing), and following a suggestion made, I started to think about the possibility to completely integrate my print management tool into Konqueror. That's done now: I turned my main widget into a part that can be integrate into Konqueror for complete management. So with:

You end up with a nice integration of the whole print stuff into Konqueror. I'll commit the code to CVS once it is unfrozen. Meanwhile, I have some screenshots available.

Michael made the screenshots available for viewing at As for the code itself Michael said that he imported the code into kdelibs/kdeprint and kdebase/kdeprint but that the new capabilities aren't part of the 2.2 build system.

7. KDE for Windows?

26 Jun 2001 - 27 Jun 2001 (17 posts) Archive Link: "Qt/Windows Available Under New Non-Commercial License"

Summary By Rob Kaper

People: Matthias PosseldtEric LaffoonRik HemsleyMatthias EttrichRichard Stevens

Matthias Posseldt wrote in: " Trolltech's newest announcement could help efforts to port KDE to Windows, don't it? Since we don't charge anyone, there should be no problem!" . Eric Laffoon answered: "Not exactly no problem, as Matthias Ettrich pointed out on LT today. There are issues with the GPL."

Rik Hemsley added: " KDE's libraries are LGPL, Artistic, X11 or BSD licensed, so they're ok (not sure about X11, but the others) - but most KDE apps are GPL, so the authors would have to insert the clause mentioned by TT or relicense. " while Richard Stevens recalled another effort to have KDE applications under Windows.

8. New SASL Library

28 Jun 2001 - 30 Jun 2001 (8 posts) Archive Link: "PATCH: New SASL library"

Summary By Aaron J. Seigo

People: Michael HäckelDirk MuellerKurth Granroth

One of the strengths of Open Source development is that active projects are "self healing". A few weeks ago the ksasl library, which provides a method for adding authentication support to connection-based protocols, had to be removed from KDE CVS due to licensing issues. Many of the network related ioslaves relied on this library so it could have been something of a show-stopper for 2.2. Of course this could not be allowed to happen so Michael Häckel, one of the primary KMail developers, stepped up to write an SASL library from scratch. He announced his success saying:

Attached a new SASL library. It has basically the same functionality as the old one plus LOGIN authentication. It is completely rewritten from scrach according to the instructions given in the RFCs. I might add DIGEST-MD5 later.

You also find the patch to make the pop3 io slave using it, for the case someone want's to test it. I don't want to change the pop3 and the imap slave to use that library before KDE 2.2, since they currently also work very well without it.

However the smtp slave could be ported to use this library. It is anyway currently not compiled by default, because it doesn't compile at all.

Kurth Granroth suggested that it should be imported into CVS immediately so that work can continue on the parts that require SASL but that it shouldn't be build by default. Dirk Mueller disagreed saying, " There is no point having it in CVS when its not compiled and not used. I don't see the problem with it, it should be a full dropin replacement because the old implementation (which was there already before the feature freeze) had legal issues, thats all." Michael agreed and added, " I actually also don't see a problem with compiling it. Also the smtp io slave could be compiled. Even if it is not used by any application inside of the CVS, maybe a third party developer might want to use the sasl library or the smtp io slave that will come with KDE 2.2. Regarding the smtp slave I just have to note, that it compiles now with the new library, but I didn't test, if authentication works again. I have to look for an smtp server that requires authentication first."







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License, version 2.0.