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.
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 ftp.gwdg.de.
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!
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: http://www.extreme.indiana.edu/soap/sc00/paper/index.html
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.
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.
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
http://www.uni-karlsruhe.de/~Daniel.Hermann/Capitalist/
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.
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
http://www.ipso-facto.demon.co.uk/development/konq-cervisia2.png. 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.
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.
- print IO slave that allows print system browsing
- print part for management
- addition of a service in virtual folders of the Konquy sidebar
Michael made the screenshots available for viewing at
http://users.swing.be/sw286000/.
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.
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.
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.
