Hi KGet team (and KDE community), I'm the kuiserver developer (well, the one that rewrote it). I see necessary that we talk about kuiserver and kget2 !! So many people have told me we are going in somehow in the same direction, and that our work could be merged (or something) somehow.

The kuiserver point is to have a KJob inherited class, and with the right signals and calls to the Observer class, the kuiserver is notified through dbus about that data, and shown. A big amount of different data can be shown, which file, from where (or device), to where (or mountpoint), the progress, the speed, an info message... that sort of things.

It allows you to add what right now are called "capabilities". I added some functionality to KJob that lets you add it capabilities (Pausable, Killable...), and then, the kuiserver will show buttons for those actions. Those actions list can be extended for new needs, of course. So by now, on download/copy jobs, you can pause/resume it, or cancel it.

I really know KGet2 has some other interesting features. Like multithreaded downloads, torrent support and so on. Some people have suggested me to merge KGet2 and kuiserver. Well, I want to place my point of view of all this: kuiserver goal is not to give multithreaded downloads, or torrent support. No. And notifying the user about a file local copy operation (for example) is not a KGet2 goal. So, the question here is: what we can do.

1) kuiserver allows to inform about downloads, and whatever you can imagine that inherits KJob, and iteract with them with the capabilities support. 2) KGet lets you interact with downloads, and will give nice support like multithreading downloads, mirroring search, torrent support...

I always have wondered (and suggested sometimes on k-c-d) why we hadn't  the possibility of queueing downloading jobs on konqueror (or in kde in general). It is possible on kget. Well, I haven't talked to David or Kevin what they think about this, and probably I'm totally wrong, in that case, just correct me :). From my point of view, KGet2 has *VERY INTERESTING* features, but nothing that can't be added to kdelibs (or somewhere else). If we could give multithreading downloads to KIO::Job, what would you say ? Great !!. That's the point. Torrent support can be handled in many ways, like writing a KIO::slave, so we could give Konqueror the capability of that too (in addittion to multithreading downloads in kio::jobs, for example), or the power to queue jobs natively (no with an "external" app).

Now what I really want to point out is that I'm not against KGet2 in *ANY* way. I find it important to know what the KGet2 developers team think about all this, and act, always thinking of a better KDE desktop, that is for what we are all here. My goal is not to kill KGet2 as it can seem at a first view, I repeat it.

Obviously, waiting for comments. :) Thank you and bye, Rafael Fernández López.