kuiserver and kget2 issues

[Rafael Fernández López]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070204/8774ca4c/attachment.htm>
-------------- next part --------------
_______________________________________________
Kget mailing list
Kget at kde.org
https://mail.kde.org/mailman/listinfo/kget